Implementing ARA and DevOps requires change - and change can be painful and is often resisted. Here are some pointers on how to make your ARA implementation project go smoothly.
When you implement your ARA solution you’re going to be asking some of your resources to perform more of the release cycle than they are used to, and others to let go of some of their involvement and hand off some of the work to other members in the process.
If you’ve been working with Agile, taking a note from the Agile Manifesto, your team members should be ready to adjust their methods and frequency of interaction. But you also need to be sure that they will accept automation solutions and the new/adjusted roles that they will play within the organization.
You might find that you are meeting resistance from the team to take on the automation because they are fearful their roles may become redundant as a result. It’s important, then, to work with all the individuals and management team to ensure the message communicated is about the business working faster, better, with less risk and that their talents can then be fully harnessed to continue to deliver more value, faster.
Some organisations, particularly those that have been acquisitive, are able to forecast that they will have an increase in applications/releases/workload whilst knowing that their headcount is unlikely to increase, may even be planned to decrease. ARA solutions can help teams do more with less.
At Ranger4 we live by the mantra “people > process > tools”. People come first, finally tools - but just as tools are worthless without process, a process can only be fully optimised when it’s automated using tooling.
Before you implement your ARA solution though, you need to review the process you have, identify how it will look in the new world, document, mandate and communicate the new process and then carefully monitor its introduction. It’s unlikely that everything will be right the first time and so you’ll need to manage expectations in this phase and create an environment of continuous improvement. It’s worth thinking about the DevOps tenets about not fearing or punishing failure (but failing smartly) and about not allowing a culture of blame.
Configuration and Build Management
It’s important to check your configuration management process and tools and the same for build before you embark on your ARA implementation - you will want your release and deployment processes to pull quality assured, version controlled code from these repositories.
Choose your project
One of the key benefits of an enterprise ARA solution is being able to use a single process and tool for deployment of a multitude of applications across multiple platforms - but it’s best to choose one place to start. Here are some projects that are often used to kick off an enterprise ARA deployment:
- Building a PAAS
- A major middleware upgrade
- Application server/platform migration
- Critical business application update
- Application migration/integration through acquisition
- Rearchitecture for DR/HA
Create a Production Like Environment
As soon as you have your project in mind, you should design a production-like environment as a starting point for development. This environment will likely be smaller but should use the same operating systems, middleware, and configurations as the production environment. UAT is one of the four typical environments of the SDLC and provides an opportunity to test in a production-like environment. Production resources that are unavailable to test environments should be simulated through service virtualization, if possible.
A production-like environment improves the accuracy of your testing for both the application and deployment processes. You can simplify your environments as you work your way back to earlier environments and remove unnecessary components.
Involve your operations teams as early as possible - don’t save the critical final deployment to production for last and hope for the best. Allowing these teams to step in at the beginning of the software development lifecycle allows the development teams to develop and test their builds and leaves the operations teams free to test and deploy the applications. It also ensures a self-designed environment to keep a working application in working order. Shifting some of the business responsibilities to development (shifting left) improves coordination between development and operations and expedites the whole process.
Practice production-style deployments
If the ideal state that you want to achieve is a streamlined release consisting of automated deployments, you need a consistent, repeatable process. To achieve this process, start by practicing production-style deployments that can be simplified for earlier environments. The environments themselves should also be as similar to production as possible. In a new implementation, finding a project that can adapt to this criterion is key.
Design for production first
Since production is the most complex environment, deployments to earlier environments should be designed as simpler versions of production deployments.
Designing the process for production first enables teams to:
- Practice before the critical final deployment
- Have a template for the processes toward the beginning of the development lifecycle
- Refine and further streamline the process. Automation furthers this goal by stabilizing previously manual steps in a complex process and reduces unnecessary effort in future deployments through repeatable, consistent templates
- Eliminate the disconnect in deployment process complexity between earlier and later environments.
Starting the design process in development prevents alignment with the goals of the operations teams, since a self-designed, self-tested process cannot reach the level of complexity that operations teams need.
Developers focus on testing their individual contributions and the representative piece of the entire application that applies to their function in the project. For this reason, developers often don’t take into consideration (or don’t know what’s needed) to keep production environments stable and functional. Due to the magnitude and scale of what needs to be tested and functional in production, the deployment process shouldn’t be designed by teams that aren’t familiar with the production environment. This is inevitably why allowing developers to design a Continuous Delivery process as an extension of Continuous Integration stops before Production and hits the wall of Operations.
To fully align your teams and facilitate collaboration from the start of a project, it’s essential to acknowledge the importance of starting with the most complicated processes and removing steps to simplify them. It’s easier to remove steps than to add them during an outage.