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
- 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:
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
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
Cascade assumes the hosting provider (like Contegix) is providing infrastructure backups that protect against
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
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.