To properly do CI/CD, you should be testing code changes before merging to main. Conceptually this is quite intuitive, but in practice it takes a lot of work:
- Staging/prod parity: your pre-production infrastructure needs to be capable of supporting your full E2E suite — all integrations, data, and dependencies.
- Branch-based deploys (ephemeral environments): you’ll need an environment with your new code changes to test against, and to share with Product and QA for UAT.
- GitOps: your environments should be auto-provisioned/updated and your CI pipeline should execute on code events, e.g. opening a PR/MR, pushing a commit.
Many engineering orgs are adding automated branch-based deploys to their roadmaps. Let’s look at why they’re becoming a top priority for shipping quality software.
What are branch-based deploys?
Branch-based deploys are full-stack environments that reflect a given branch in your git repository down to the latest commit. They’re often used to preview and interact with new code changes in a production-like environment — this guarantees more confidence in every production deployment. They are also commonly referred to as ephemeral environments, preview environments, review environments, or sandbox environments.
Most of the time, branch-based deploys are created at the pull request level. They’ll then update with every additional commit to keep up-to-date with their git branch.
Branch-based deploys for CI pipelines
Branch-based deploys are especially valuable when they can be leveraged by your CI pipeline (CircleCI, GitHub Actions, Jenkins, Harness) for automated testing. Instead of testing your code changes after you merge their respective branch, you can test the branch directly in an isolated environment. This keeps you moving forward — you’re fixing your code changes on the spot, instead of trying your luck and potentially breaking staging.
Adapting your CI pipeline to work with branch-based deploys is light work, since you’ll more or less shift existing CI jobs left from your staging pipeline. It’s also best practice to use a similar set of E2E and integration tests for both branch deploys and your staging environment. Branch-based deploys are meant to have similar infrastructure to production, so they should simulate real-world application performance when tested against.
Branch-based deploys for code review
Code review gets time-consuming when you’re dealing with the “but it works on my machine” blocker. Everyone’s local dev environment will be slightly different by default; your team is likely working across different OSes and will be dealing with varying dependency versions. For this reason, your local dev environment isn’t really a prime candidate for quick code reviews.
When you send a PR/MR link to your teammate and request their review, it can be helpful to send them a link to a cloud-based deploy of your working branch. This not only gives them more context for your code changes (without the overhead of spinning up the branch locally), but also lets them interact with and UAT the branch. Since branch-based deploys also approximate production closer than your local environment, they’ll also be able to see how the code changes mesh with the integrations that they can’t preview locally.
Life cycle of branch-based deploys
Cloud and infrastructure costs rack up quickly, which means that branch-based deploys must be disposable and short-lived in order to be cost-effective. These environments should have life cycles automated by GitOps — it’s inefficient to let this responsibility rest on the DevOps or Platform team.
Branch-based deploys are ephemeral-first; they’re not designed to stay up for more than a few hours at a time. A combination of factors (especially that they’re decoupled from dependencies and smartly utilize build caching) mean that they can provision and build within minutes, often responding to a repository-based event as a trigger.
When not in use, it’s best practice to automatically spin down branch deploys, ideally scaling to zero. The best infrastructure is on-demand. In order to get closer to true on-demand infrastructure, developers shouldn’t have to remember to turn off environments.
Branch-based deploys vs. cloud dev environments
While they may seem interchangeable at surface level, branch-based deploys serve a different purpose from cloud development environments (CDEs), the main distinguisher being that branch deploys are used as post-commit environments. In your development workflow, you’ll typically use your local or cloud dev environment for iterating in the inner loop. Once you need a more production-like environment to verify and test your changes, you’ll then spin up a branch-based deploy.
While branch-based deploys aren’t designed for long-form developing like CDEs are, they still stay up-to-date and rebuild with code changes pushed to their source branch. This is particularly useful for resolving bugs or making quick edits on the spot.
Shipyard for branch-based deploys
If you’re looking for a zero-config branch-based deploy system, check out Shipyard. You’ll get automatic, full-stack branch-based deploys on every PR. Here’s how it works:
- Sign in with your git provider: connect your GitHub or GitLab account and grant access to all or specific repositories.
- Create a Shipyard application: from Shipyard’s developer dashboard, you’ll create a mono or multi-repo application, select base branch(es), and import necessary environment variables.
- Open a PR/MR: as soon as you open a pull request or merge request, Shipyard will spin up a production-like copy of the branch you’re proposing for merge.
Talk to us to see what this looks like for your org. Or kick off a 30-day free trial to build your technical PoC.
