The following are common questions we get about how to use Cascade in typical operating scenarios.

Q: What is the difference between a Deployment Target, a Deployment Group and a Deployment Environment?
A: Deployment Targets (DT), Deployment Groups (DG) and Deployment Environments (DE) are different levels of abstraction that allow Cascade to deploy code, assets, and databases to the right servers.
  • Deployment Environment - all the computing resources required to support a site. This is usually a collection of one or more database servers, file servers and or web servers. For example, a dev environment may only have a single multipurpose server hosting both apache and mysql. Or alternately a production environment may have two database servers, four webheads, and two file servers, and additional caching servers.
  • Deployment Group - all the computing servers of a certain type within an environment that should be treated as a unit. We sometimes do not want to deploy code to a database machine or copy a database to a webhead. In these scenarios, all of the webheads are put in a deployment group named, for example, “Code,” and all databases are put in a deployment group named, for example, Databases. Each deployment group also has a primary and some actions only happen on the primary. For example, a database is not imported into all members of the deployment group - only the primary.
  • Deployment Target - a computing resource where code, assets or databases are deployed. We currently only support linux servers as deployment targets.
Q: Can I set up my development, staging, and production environments all on the same server?
A: Yes. Cascade separates the concept of a Deployment Environment from the concept of a Deployment Target. In this case, you will create a single Deployment Target and then configure your Environments to each use the same Deployment Target.
Q: Do I have to put all Deployment Targets into every Deployment Environment?
A: No. In fact, in most cases you shouldn’t. Normally your production environment will not share any common deployment targets with the development environment.
Q: How do I commit code to my project?
A: Part of Cascade is an install of Gitlab, which is based on git. There are many tutorials on the web on how to use git, but as a quick start to import your project, use:

Create a local repository:

git init
git add .

Push an existing (or newly created) repository into Cascade’s git:

git commit -m "First commit"
git remote add origin <url>
git push -u origin master
Q: What roles does Cascade support?
A: For each project, Cascade creates the following roles with the following permissions: Administrator, Manager, Observer, Developer, and Deployer For more information see the Portal roles guide.
Q: What is a Role Group?
A: Some customers want to restrict access per project. Others want to apply a role to all projects. Cascade supports both models where you can either give a user project roles, or give them a role group, allowing a user to have that role in all projects both retroactively and for future projects. So for example, a person can be a Project Developer in just a few projects, but have the Project Observer role group, allowing them to see all projects. There is also the “Cascade Admin,” which essentially means that the user has access adding/removing users and has unrestricted permissions.
Q: How are user and project permissions managed in Gitlab?
A: Cascade uses Keycloak Single Sign-on to manage users in Gitlab but does not manage Gitlab permissions. Your “Cascade Admin” can log in to Gitlab to manage permissions via Gitlab’s permission controls.
Q: How is my data backed up?
A: Cascade creates on-disk database snapshots when databases are merged between environments or when manually initiated via the database snapshot button in the project dashboard.
  • Database snapshots are stored in /opt/backups/mysql/
  • Manual on-demand snapshots of database groups are also provided by Cascade as a clickable button in the project dashboard.

Cascade assumes the hosting provider (like Contegix) is providing infrastructure backups that protect against infrastructure failure.

Q: Can I roll back a deploy?
A: Rollbacks are possible and are handled differently based on the data source as follows:
  • Code: Since Cascade deploys whatever is in your git repo, you can roll back a code deploy by resetting or reverting the code in your repo and re-deploying.
  • Databases: may be manually restored from snapshots taken by Cascade and nightly backup systems. Users comfortable with CLI may use restore themselves or place a support ticket to re-import.
  • Assets: rollbacks are only supported through a support ticket based on the machine level nightly backups of your deployment targets.
Q: Does Cascade support post-deployment actions?
A: Both Pre and Post Deployment actions are handled by the deployment pipeline configuration. Actions may be placed after the “Deploy Code to [ENV] step.