FAQ

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: 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:

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.