Self-service DevOps: speeding up environment availability

James Ward
James Ward | 20 December 2017

How often have you worked on projects where the developers have had to wait days, or even weeks, to get a new test environment set up, slowing down delivery into production significantly? 
At IndigoBlue, we work closely with clients to establish good DevOps practices. One such practice is to empower developers to be able to provision their own test environments. A client I've been working with has put in place some great automation in this area.
The client provides personal fitness mobile apps. The apps use a set of backend RESTful endpoints in order to offer personalised workouts to users and then to submit details of their completed workouts. The backend is implemented in Ruby on Rails and deployed as a set of Docker containers managed by Kubernetes.
They have five multi-disciplinary Scrum teams working on new features with frequent releases involving mobile and backend changes. They currently use short-lived feature branches to enable each team to develop stories independently. Each workstream needs to be able to integration test their small incremental changes quickly before merging.
They have developed tooling which enables developers to easily setup/refresh test environments on demand. The list of backend components to deploy, and their versions, can be fine-tuned with ease. The backend components are populated with representative production data ready for testing. The environments are deployed on a dedicated shared Kubernetes test cluster hosted in Amazon AWS, using namespaces to cleanly separate each environment. The tool can be invoked using a Jenkins job but they've also used hubot to make it as easy to run as sending a Slack message.
Once changes are tested, they are merged into the development branch, tested via a Continuous Integration pipeline and deployed into a shared staging environment containing the ongoing work of all the teams for final pre-release testing.
What’s really key is how much time and frustration this DevOps approach saves for all concerned, while also allowing expertise to be redirected towards other important areas.
Developers also co-ordinate amongst themselves to release their own changes into deployment by running a Jenkins job. No Ops team involvement is required for provisioning test environments or rolling out releases, freeing up their time to focus on improving the tooling and managing the infrastructure.
Find out how our DevOps+ practice can support your organisation to achieve similar results in optimising the work of your Development and Operations teams.