The benefits of automating the setup.

• Makes an engineer’s life easy by taking away pains of setup
• Eases the burden of costs for companies
• The setup itself will become an onboarding document and will be validated with every (new) team member trying to set up their machine.
• Consistent setup across the team and thus helps in the effective pairing
• Get rid of the “works on my machine” phenomenon
• Helps in keeping the tools upgraded

Why we used Slack for communication.

Equal Experts already used Slack for effective communication with client teams. It is very easy to have instant conversations but also keep track of what happens elsewhere. A Slack channel could be created ad-hoc for a specific issue. Engineers, analysts and designers from multiple teams and specialisations can focus on collaborating and solving problems without endless meetings or endless email chains.

• Questions for a specific team – the team uses public team channel as the first option.
• Private Slack channels – for the day to day internal discussions that don’t need to be aired in the public.
• A consistent naming convention, with good channel descriptions.

How to deliver at speed – Self-Service + Infrastructure-as-code.

The other really important aspect of working at speed is that as much as possible can be achieved using self-service. Logs, performance monitoring, automated alerting, a build pipeline that would automatically build and deploy to the non-production environments. It would even configure a Pull Request Builder that would run the tests before committing to the main branch.

An engineer’s point of view.

A really important aspect of working at speed is that as much as possible can be achieved using self-service. Here is a view from one of the engineers on the project:

“Within next to no time, I had all the supporting components in place. Logs, performance monitoring, automated alerting, a build pipeline that would automatically build and deploy to the non-production environments as soon as I committed to the main branch. It would even configure a Pull Request Builder that would run the tests before committing to the main branch.

All this was done in a matter of minutes, giving me time to focus on writing the service itself.”

You Build It, You Run It.

HMRC wanted to give the MDTP team all the capabilities they needed to develop, test, deploy, and operate their own live services. We supported HMRC to adopt a “You Build It, You Run It” approach, something we at Equal Experts use regularly to ‘upskill’ and empower our clients’ teams. This has been a key enabler to supporting so many teams on the MDTP. A Platform-as-a-Service offering maximum operability with minimal friction is easier for teams to operate safely and reliably.

The production support method of ‘You Build It, You Run It’ refers to developers supporting their own production services. You Build It You Run It unlocks weekly or more frequent deployments for Digital Service teams, as it eliminates any operational handoffs. It also incentivises Digital Service teams to balance their time between product and operational features. The net result is more frequent production deployments and more reliable live services.

Find out more about You Build It You Run It. 

How does Continuous Delivery work?

• We start projects by building a “walking skeleton,” automating the path to production.
• This is an end-to-end slice of working functionality.
• It proves the architecture, path to production, and a foundation to build upon, incrementally.
• We then automate the process of building and testing software in a repeatable and consistent way, from development, through test and into production.
• We incrementally adopt continuous delivery and build a deployment pipeline to give us confidence the same software is deployed and tested through each state.
• This confidence allows us to release early and often, with small enhancements directly responding to customer feedback.