1-888-310-4540 (main) / 1-888-707-6150 (support) info@spkaa.com
Select Page

Electric Flow Feature Highlight: Environment Reservations for Confident Deployments

Deploying modern software applications is a complex process involving many moving parts. Adding microservices into the mix amplifies this problem by further decentralizing applications, resulting in more deployment endpoints to track. With all those IP addresses floating around, one of the worst fears of any DevOps engineer is someone accidentally deploying to Prod or any other sensitive environment. To guard against this sort of situation, Electric Flow has safeguards built in that allow you to restrict when and how operations can be performed on a given Environment.

Electric Flow employs a model-based approach for describing the various Environments that make up a deployment pipeline. Frequently, this looks like separate Environment definitions for QA, Staging, and Production, with many companies opting to throw in task-specific Environments for things like performance testing or user acceptance testing. Each of these Environments can be enabled or disabled. Disabling an Environment is probably the easiest and most basic way to prevent someone from accidentally targeting the wrong endpoints. It prevents any deployment operations from taking place on the machines mapped to that Environment. This is a good start, however there are much fancier things we can do.

Environment Reservation is a powerful, new feature focused on making deployments more reliable and predictable. There are two types of Reservations to help achieve that aim.
Each environment has a toggle for “Requires Reservation”. If this box is checked, it means that any operation you want to perform on an environment needs to be pre-scheduled. The reservation can be “exclusive” or “non-exclusive” and requires that you specify a start and end time for which the Environment will be available. Exclusive reservations basically set it up so that only a particular operation at a particular time is runnable. Non-exclusive reservations allow any operations to run during the designated window and are useful for performing multiple deployments at once.

One of the neat features of Reservations automation of schedule deployments once the window is open. If you schedule a Reservation and then run your process, Flow will wait until the window is open before performing the operation. Depending on your level of confidence, this means you could line up your deployments to happen overnight – unattended! If dealing with a pipeline, the pipeline will start right away, but the deployment task will be blocked until the window is open.

A second form of Reservation is the Blackout. Effectively the inverse of a Reservation, a Blackout allows you to define periods of time when an Environment is off limits while leaving all other times open for deployment activities. This type of setup is useful for situations like blocking activities during business hours, or perhaps a period when hardware is being physically swapped out. Much like simply disabling an Environment, Blackouts have the added benefit of allowing for automatically repeating schedules so you can set and forget.

Electric Flow is an excellent orchestration tool for managing the complexities of modern deployments. Even so, it can become complicated itself and when you throw more people into the system, it’s good to have an added level of assurance that accidents are difficult to commit.

David Hubbell
Sr. Software Engineer
SPK and Associates

Latest White Papers

Related Resources

AWS re:Invent 2022: Everything You Need To Know

AWS re:Invent 2022: Everything You Need To Know

Miss out on AWS re:Invent 2022? Or, just looking for a recap on the latest AWS updates and releases from the event? Check out the summary below. What is AWS re:Invent? AWS re:Invent is an annual conference hosted by Amazon Web Services (AWS) for developers, customers,...

Solving for the “Islands of Jenkins”

Solving for the “Islands of Jenkins”

In October 2022, I wrote a blog post entitled “Scaling Jenkins for the Enterprise”.  Within it, I described the “Islands of Jenkins” problem organizations face. Essentially, this problem stems from companies using an open-source Jenkins installation for each team, but...

Infrastructure as Code with Terraform

Infrastructure as Code with Terraform

Before we begin to talk in detail about this topic, we should clarify some definitions first.  The first term comes from the DevOps movement where IT Operations staff use the concept of revision history/version control by using the concept of infrastructure as code. ...