Automation – Confidence as a Service

Keys, wallet, phone. Check, check, check. Did I turn off the oven?

Confidence is important – reliance on your memory invites doubt, and with a multi-million business reputation at stake, you need to know for sure.

Our goal is to help teams ship software faster — without compromising on quality and with peace of mind – every time. It’s a difficult challenge for any organisation. It’s made possible by harnessing the power of automation and continuous delivery, creating end-to-end pipelines that can orchestrate the appropriate build, environment provisioning, deployment, and rigorous automated testing of software.

To demonstrate possible uses of automation in the delivery lifecycle, I want to take you on a quick tour of a basic delivery pipeline, covering some of the stages we can automate.

Static Analysis / Linting

It’s important the team follow the coding rules set out by themselves, and automated low-level checks against the codebase after every change can ensure this is the case.

Rules vary from simple, such as enforcing consistent indentation or use of correct quotes, to complex ones around types, casting and declarations.

Unit test

It’s called unit testing because it checks the smallest components – units – of the code: functions. Each function has a single unique and important responsibility.

Let’s take for example a function that returns the calculated percentage change of an investment – unit tests might check that the function behaves correctly with an increase in price, a decrease in price, no price change and that it returns two decimal places. At this stage we can check the unit tests pass, coverage thresholds are met and that the tests are effective.

Integration test / component test

A functional component – a form to fill, or a login window, has a number of functions, or units, working together – often involving a database or a service. Where a unit test would test the function in isolation, an integration test would test the function working with its peers.

In the percentage calculation mentioned before, it’s likely the previous price and the current price are retrieved from an additional service. An integration test would ensure that service is called, a response is received in the correct format and is understood by the receiving function.

Security

You can run, but you can’t hide!

Vulnerabilities are scary and exist in all code – some are new, some are old and freshly discovered.

An increased pace of change, granting us the latest and greatest, also increases the risk of introducing fresh vulnerabilities into our software. Automated security checks afford us essential, continuous protection from vulnerabilities in our code and the third-party libraries we use. This includes security static analysis, an audit of external dependencies and audit of our hosting environments. All these checks are part of our delivery pipelines.

End-to-end test

If only we had a mechanical human patiently clicking through our website / mobile app and checking all the functionality users rely on!

Well, we do that. Human user emulation is what E2E tests do, on a full, real test system replicating a journey our customers would take when using our platforms, such as logging in to view a portfolio.

Tests are written in a readable format called Cucumber, which emphasises fluent sentences and logical order of ensuing actions:

Given I login as an AJ Bell client

When I choose to view my SIPP portfolio

Then I am displayed my holdings

Version and documentation

Each time we release new content, we package it under an easily communicable version number. It has a special format, called semantic version, where the size of the change – MAJOR, MINOR or a PATCH increase respective digits in version tag eg. v1.0.0 becoming v1.1.0. It's all automated based on what developers write in their commit messages AND it generates pretty documentation relating the change that happened.

Deploy

Houston, ready for launch.

Getting code from a cosy repository to the end user sounds simple, but it’s historically a multi-team effort. Business likes change, check. Testers approve the change, check. Virtual machinery is primed and ready? Infrastructure Team approves.

Humans waiting on each other, talking, miscommunicating – it takes a while.

Pipelines streamline this by orchestrating consent and of course all the actual actions! Seamless, fast and reliable.

If any of these stages fail?

The pipeline stops and alerts the correct team immediately to remediate the issue as soon as possible.

I’m ready already!

Deployment used to take hours! Now it’s minutes. Then back to productive work – rinse and repeat. Multiple times a day – no problem!

With a standard template across teams, it feels easy.

By Matt, Platform Engineering Lead