Stream of Consciousness

8-levels of Deployment Maturity

As projects gain importance, the way in which we develop and deploy should change. For startups and side projects, pushing maturity too early will result in a lower delivery feature rate. Meanwhile, for larger organizations a paved road is ideally created and maintained to meet operational standards. These are my initial thoughts on maturity levels.

Level 0: Runs on My Machine

You’ve got a script or application which runs on your machine. It solves some sort of problem somewhere; however, the solution space is fragile. Running on another engineer’s machine might work.

Level 1: Ship directly to production

It’s deployed manually to a manually configured production environment. Not automated nor ideal. However you get it into the user’s hands. You can rapidly iterate on improving the solution space. Since you now have two environments ( your local sandbox and production ) the build is a bit more stable.

Level 2: Source Code Management

Your project has a repository in your chosen source code management system (de jour being Github). You can now easily iterate on improving the solution space. Other engineers can checkout the code and run it locally. Features are still deployed manually, but you’ve got versioning attached to it.

Level 3: Packaging

Pushes to your main branch now produce artifacts for each version. This could be a container image, an app bundle, or maybe just binaries. You can track defects to specific versions and releases. Although you might produce a package they are still typically deployed manually.

Level 4: Unit Tests

You’ve reached point you need confidence. The solution space has grown larger and possibly with multiple contributors. Unit tests within your repository are now a requirement or strongly encouraged. They help you from destroy user confidence with your releases and move faster while developing.

Repository-specific test steps are automated into your continuous integration pipeline.

Pull requests become required at this point so you know if you are breaking things.

Level 5: Continuous Delivery

You finally have a fully automated pipeline into your last pre-production environment. If you live dangerously, then the pipeline might extend all the way into production. Perhaps you have feature flags for safety.

Level 6: Application-level Integration Tests

You spin up your application with critical dependencies and verify at a code level it works. For example, you might spin up a database like Postgres and exercise key functionality. Or minio to ensure you can resize images.

These are wired into your continuous integration pipeline as a gate. Pull requests must pass both unit tests and integration tests.

Level 7: System Integration Tests

You can spin up your entire application stack and verify it works. This includes dependent applications and configuration of infrastructure. You run batteries of automated tests to ensure your application is working as expected.

Your pull requests now check for these tests to pass before allowing a merge.

Level 8: Continuous Deployment

Confidence abounds! You trust your pipeline to deploy your application to production after your battery of tests confirms they work. You are able to orchestrate any component release with ease.