1. Introduction

This section provides a very high-level overview of the Release Engine and it’s component parts. Let’s begin with a high-level overview of the complete system.

1.1. Overview

This section is a narrative, or story, introducing us to the individiual roles each component plays in the Release Engine. At the end of this narrative we’ll have learned:

  • Overall workflow
  • About the key components
  • How components communicate

1.1.1. Scenario

We work in a software shop and we have been told to decrease our time to delivery. We took some measurements and realized that even with Jenkins and some home-brewed systems for deployment, we’re still spending ≥ 20% of our sprint time on just deploying to test environments. Let’s focus on getting back that 20%.

How do we approach this? What functionality must be present in any kind of system which can automate deployments? Also consider that we’re just one stop in a much larger shop. Given that constraint, it follows that whatever we build should be accessible to outsiders, extensible so other teams can build on it to fit their requirements, as well as have a clear language for describing steps in a release.

  • Authentication and authorization
  • Storage for deployment playbooks
  • Loosey coupled components, so individual installations can scale to meet their owners requirements
  • Something to manage all of the actual steps happening
  • And, some sort of configurable notification system, so we can get updates in real time.

When used together, the Release Engine provides all these things.

1.2. Components

The Release Engine has three required components. Each of which is documented thoroughly in its own separate section. The following are brief descriptions of each component.

  • RE-CORE
    • A finite state machine which oversees the execution of all steps required to complete a release
  • RE-REST
    • A REST endpoint which handles authentication/authorization
    • The primary point of interaction for clients
  • One or more workers
    • Workers are the components which are actually executed as release steps
    • There are several pre-built workers, you can view them on github

In addition to the required components:

  • RE-CLIENT
    • Command line took for easily interacting with the Release Engine
    • Create, read, update, delete, and run playbooks

1.2.1. Component Diagram

_images/ComponentDiagram.png

1.2.2. Interactions & Workflow

This section describes how the Release Engine components interact with each other and the supporting infrastructure. We’ll review these interaction by examining a typical workflow.