Heroku CI/CD
Heroku Flow
You’ve written great code for an application- now what? Depending on the size and structure of your organization, testing, branching, and deployment may be handled in different ways. In a large organization with highly specialized departments, developers may hand off new features or bug fixes to other teams to handle integration and deployment. Smaller teams may rely more on the developers to handle operations processes or testing. Perhaps you’re an army of one- in that case, you’re responsible for the whole pipeline to get your code from your local machine to production. Regardless of scope, application deployment can be a complex process with several moving parts. To manage the developer-to-user pipeline, teams often use a workflow known as “CI/CD.” CI/CD typically refers to “Continuous Integration/Continuous Delivery.” CI/CD workflows grew out of the application of Agile Development practices to integration and delivery processes.
“Continuous Integration” and “Continuous Delivery” can mean something different to everyone, but there are broadly defined features that define them. Continuous Integration refers to a development practice where changes to a codebase are pushed to a version control repository and merged into the master branch frequently. Typically, these changes trigger testing to verify integration, though tests are not strictly part of the definition of CI. Continuous Delivery is a logical “next step” to Continuous Integration. Continuous Delivery is a delivery model involving frequent builds, short release cycles, and automated processes. Like CI, CD workflows frequently feature automated testing that ensures the changes being pushed work properly before being released.
Heroku Flow is a continuous delivery solution available as part of Heroku, a platform-as-a-service provider. Heroku Flow incorporates several features of the Heroku system into an integrated process. Heroku is designed to be a developer-focused product, so individual elements of Heroku Flow were built to solve specific problems faced by internal Heroku developers, or users of the platform. In our interview with Andy Appleton, an engineer on the Heroku Flow team, he described how CI/CD tooling was a natural outgrowth of the Heroku platform, but that the overall evolution of Flow was a piece-by-piece process that was later integrated into end-to-end toolset.
“The way that our team likes to work is we picked one feature that we could deliver in a fairly short amount of time, which was the automatic deployment piece at the beginning. Then we think to ourselves what feels like it’s missing now. Where is the pain point? Then we build review apps. Then once we’ve got review apps, then you start saying, “Well, there’s no formal definition of staging or production. Then we start to think about pipelines and it sort of rolls on one thing to the next to the next.”
Even though Heroku Flow was built in an evolutionary process, the Heroku team has organized the various functions created for CI/CD into a structured deployment workflow. Overall, Heroku is an opinionated, convention-over-configuration platform, which uses plug-and-play components to abstract away some of the lower-level infrastructure tasks. Heroku Flow fits within that design philosophy by building visual tools to manage some of the more abstract or complex stages of a CI/CD workflow. For example, Heroku Pipelines takes the multi-environment testing and deployment process and makes it visual. The environment feels similar to a Kanban board system like Jira or Trello, which are familiar technologies for developers working in an Agile environment.
Pipelines also work with Heroku CI, a “low-configuration test runner” that allows easy automated testing. Moving code from one stage to another can be done manually or automatically, and tests can be applied at any stage. Heroku CI uses “disposable apps” that run quickly and have a strong test/prod parity since Heroku has access to the production environment configuration information. Developers can also use Heroku ChatOps to move code through pipelines via a Slack integration, and receive Slack notifications about pull requests, test results, and merges.
Heroku Flow provides Review Apps, which are temporary test apps spun up for every opened pull request on GitHub. Review Apps provide a convenient way to allow any user in an organization to take a “test drive” of the code in a given pull request, which is especially helpful for non-technical users who may not be comfortable running a branch in their local environment. Review Apps last for the duration of the pull request and are destroyed when the code is merged. If a developer makes a new commit on the feature branch in the pull request, the Review App will be automatically updated allowing for quick iteration and rapid feedback cycles.
Heroku Flow puts Release Phase tasks directly in an app’s Dashboard, including database migration, uploading assets to a CDN, cache management, and more. Heroku already allows developers to manage tools such as Postgres databases with a few commands in the Dashboard or the Heroku CLI, and this philosophy of simplicity and streamlining carries over to release and deployment. These tasks can be run automatically, ensuring high-quality and reliable releases.
A continuous integration and delivery pipeline a number of advantages for a development team, including accelerated time to market, dependable releases, and improved developer productivity. Heroku Flow provides intuitive and effective tooling for a CI/CD workflow and is definitely worth a look for developers looking to capture the benefits of CI/CD. For more on Heroku Flow, check out our interview with Andy Appleton of Heroku, an engineer on the Flow team. For more on Heroku in general, check out our Heroku archives or visit their website.
