- Getting Started
- Example deployment to Heroku
- Using pipelines
- Deploying with Snap
- How do I add SSH keys to my build?
- Scheduling and skipping builds
- Deleting or cancelling a build run
- Billing owner best practices
- Deployment Pipeline
- The CI Environment
- Snap CI's Stacks
- Simple Docker pipeline using Snap CI
- Building & propagating Docker images
- Deploying Docker images
- Docker FAQ
- Known Limitations
- Relational Databases
- NoSQL Datastores
- Testing with browsers
- Complete Package List
- Environment Variables
- Heroku Deployments
- Deploying to AWS
- Deploying to AWS OpsWorks
- Deploying to AWS S3
- Deploying to AWS ElasticBeanstalk
- Working with Branches
- Cloning a pipeline
- Integration pipelines
- Automatic branch tracking
- Pull Requests
- Configuring multiple workers
- Speeding up builds
- Setting up test parallelism
- Pipeline Parallelism
- Polling project status using CCTray
- Webhook notifications
- How Snap integrates with GitHub
- Revoking privileges granted to Snap CI
- Managing membership
- Triggering Pipelines and Stages
- Migration to GoCD
- Migration to other CI and CD tools
At an abstract level, a deployment pipeline is an automated manifestation of your process for getting software from version control into the hands of your users.
Why do you need a Deployment Pipeline?
A deployment pipeline is a sequence of stages which proceed from left to right. It is triggered by changes from a version control system. Each change propagates through the stages of the pipeline. Each stage provides higher level of confidence as code is deployed and tested in environments that are progressively more production like. Each stage may publish artifacts and the these artifacts can propagate through the pipeline for use by future stages.
A stage consists of set of commands which are run to accomplish a specific purpose.
Stages may also contain environment variables that may be required by the commands in that stage. They can also generate artifacts which may be used by subsequent stages.
The stages can either be -
test stages: each evaluating the build from a different perspective
or deployment stages: which deploy your application to specific environments.
Pinning common Setup Commands
Every stage in Snap starts with a clean and isolated environment. Hence, if you made any changes to the build machine such as installing packages or build dependencies in the previous stages they may not be available in the current stage as it may be running on a different machine. You are therefore required to setup any build dependencies on every stage before running the commands for that stage. Snap allows you to do so by pinning the common setup commands. Pinning commands runs them before every stage and they are typically used for installing your build dependencies, setting up the database, etc.
Defining environment variables makes it available to all the commands in that stage. This is the same as using the
export command before running the stage.
Secure Environment Variables
Snap also supports Secure Environment Variables which are never stored in the Snap database in plain text. The values of these variables are never displayed anywhere in Snap once they are setup. We also make a best attempt to clear out any occurrences of the secure environment variables values from the console logs. To read more about this check out the Security page.
Global Environment Variables
Environment variables can be pinned just like any command. Once pinned, the variable will be exported on every stage.
Local stage variables are exported after the pinned ones. Therefore, the value of the stage variable will override the global variable if they have the same key. For example, given a stage with configuration like the following:
When running the stage, the value of AWS_DEFAULT_REGION will be us-west-2.
Artifacts are the outputs produced by a stage. These may include binary artifacts (jar, gem), console logs, test coverage reports etc. Snap allows you to configure any directory as an artifact of a stage. This artifact will be made available to the next stage if there is one and will also be made available as a download to collaborators.
One of the advantages of a pipeline is that generated artifacts are not just available for download, but are also made available to subsequent stages. This allows you to build binaries only once, and increase confidence in the binary with each subsequent stage. This also gurantees that you are deploying the exact same binary to an environment that you tested with.
A user can choose to add a set of secure files to a stage. Examples include ssh keys, certs or password files which are required by that stage. These files are created at the beginning of the stage and are cleaned up at the end of the stage. The content of these files are encrypted when stored in Snap and the file is made available only when the stage is running.
During the stage run, if you choose to print these files to the console, Snap will not attempt to escape the output and you may end up revealing the contents of these files in the logs.