Minimum Viable Engineering

Implementing a Continuous Delivery (CD) pipeline means automating to a large extend the decision on when to ship.

Not everyone will be brave enough to completely remove a person from the process but if we are to achieve anything like a continuous deployment of functionality that person will be basing the decision on the red or green lights of our automated testing.

So how do we build this framework of automated testing how do we know when our code is good enough to ship.

Minimum Viable Code

Code is the building block on which we build our product, the first tranche of testing needs to ensure that each of these blocks does what it claims to do, we determine this via unit testing.

If we have adequate coverage of our code from unit testing then we know that we can safely compose our system with confidence that when tested in isolation each of our building blocks is fit for purpose.

If we've followed TDD we also know that this isn't by fluke, we have seen the tests fail and now were seeing the tests pass.

By integrating unit testing into our CD pipeline we can be confident that problems at this level will be detected early, the higher the frequency of change in your code base the higher the need for this testing to be automated. 

Minimum Viable System

Just because we have developed trust in our individual building blocks doesn't necessarily mean we can build our jigsaw and just assume everything will be ok.

Part of our engineering skill is in being able to orchestrate these building blocks into a system that achieves a goal, this might be to manage a database, consume an API or process some data.

We now need to move from testing the building blocks in isolation to testing them when they are chained together.

During unit testing the interaction of code with its dependencies takes place in a controlled but simulated fashion, now we need to ensure that end to end processes give the desired result.

We have now moved from building blocks to sub-systems and verified that under the hood our code works.

Minimum Viable Product

The majority of us will be constructing software that people interact with, we provide a user experience where inputs from our users trigger behaviour within our code base resulting in output to be consumed.

Our final level of testing needs to assume the place of our users and ensure that given a certain circumstance, when a certain action is taken, then a certain result is observed.

This behaviour driven testing is the final step that determines whether or not we have something viable to ship.

A green light from those tests needs to be interpreted that we have something delivering the minimum our users expect, a red light should mean everyone stops until the problem is discovered and fixed.

We have now tested our product end to end, if we've done this on a regular automated basis then we have established several points at which we could ship.

Software is complicated, manually testing an entire product is a lengthy error prone process.

The only way to be able to deliver regularly and often is to automate as much as possible, freeing up your human resource to concentrate on more abstract elements such as edge cases and unusual activity.

Software is very good at dealing with the repetitious and mudane we should use that to ensure our code, at all levels, is continually being tested whenever change takes place.