If you read my last blog post, Introducing Pipelines, you’re probably wondering: another Pipeline feature? Well, from now on, we’re calling those pipelines Dashboards. The reason: those pipelines are not scoped to a single application. You could (if you choose to do so) create multiple pipelines containing the same application. This is cool and useful, but there is an issue: configuring automatic build and deploy settings.
For example: let’s say that you want to create a pipeline (now dashboard), and automatically deploy your application to a development environment. You create Pipeline A, and drag a pipe from the application to the dev environment. This gets you ready to promote the application to the dev environment when you want to. Now, you want to enable automatic deployments to dev.
To let you enable automatic deployments, one of the approaches we considered was adding an ‘auto-deploy’ option on the pipes. However, if the same application and environment are also part of Pipeline B, one might wonder, “which pipeline’s auto-deploy setting gets precedence?” We’d have to restrict an application to appearing in only one pipeline, or come up with some crazy “precedence logic”—the horror!
Instead of making drastic changes to the feature, we came to realize that they’re something else entirely: they’re customizable, interactive Dashboards. They give you valuable insights into what’s going on with your applications and environments: What release does this environment have? Who promoted the active release from the gamma environment to production? Did that build fail or succeed?
Nomenclature is a difficult thing to get right, and it’s hard to release something named Pipelines, and a few months later call it Dashboards. Nevertheless, we’re confident that our current and future customers will benefit from the name change. So don’t worry, “Pipelines” as you know them aren’t going anywhere. They’re just getting a name change.
Introducing Application Pipelines
Application Pipelines are scoped to an application (including the application’s repository, if connected) and its environments. With Application Pipelines, repository configuration comes to the forefront.
Actions like auto-build and auto-deploy are easy to turn on and off. It’s also easy to add and remove environments from steps, and to set up a unique pipeline for each branch (and configure the branch to build with Distelli Docker containers or your own hardware):
The core idea behind App Pipelines is automation: create an app pipeline, configure it, and things happen according to your configuration. Distelli triggers builds and automatically deploys releases from one step’s environments to another’s without you having to do it manually. You can also set auto-deploy conditions on steps, for example, “Auto Deploy if all Deployments succeed”. If a deployment fails, scheduled deployments to the next step’s environments will abort.
The core idea behind Dashboards is oversight and control: view the state of the world and take immediate action if necessary. With multiple Dashboards, you can set them up to mimic application pipelines (I like to do this) or you can have widely custom views for specific parts of your infrastructure—or even specific branches of specific parts of your infrastructure. The choice is entirely yours.
Together, App Pipelines and Dashboards work together to provide automation, oversight, and control over every step in your DevOps setup. To learn more and get started with your own App Pipeline, read the Knowledge Base article written by my coworker Brian: App Pipelines, and reach out to us if you have any questions.