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: What happens if a Deployment Target becomes Inaccessible?
A: In the event that a Deployment Target becomes inaccessible, whether it’s server downtime or the network between Cascade
and the server is interrupted, the Deployment Target is marked not ready. Any Deployment Environment that contains that
Deployment Target is then marked inactive.
Q: What does it mean to have a Deployment Environment become Inactive?
A: An inactive Deployment Environment means that it either contains invalid Deployment Targets or that Deployment Target Groups
do not have at least one valid Deployment Target. If a project is using an inactive Deployment Environment, deployments to
that environment will be disabled. You will also not be able to make changes to that project until you resolve the Deployment
Environment or remove that Deployment Environment from the project. Creating a project will also be disabled if you’re attempting
to use an inactive Deployment Environment. In both creation and editing scenarios, you can denote an inactive Deployment Environment
by the red text of the Deployment Environment on the Environment selection screen.
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.