Release

Application Release Automation (ARA) is a relatively new, but rapidly maturing area of IT. As with all new areas, there is plenty of confusion around what Application Release Automation really is and the best way to go about it. There are those who come at it with a very developer-centric mind-set, there are those who embrace the modern DevOps concept, and even those who attempt to apply server based automation tools to the application space.

Application Release Automation (ARA) refers to the process of packaging and deploying an application or patch of an application from development, across environments, and eventually to production. ARA solutions must combine the capabilities of deployment automation, server management and modeling, and release coordination. ARA tools help cultivate DevOps best practices by providing a combination of automation, environment modeling and workflow management capabilities. These practices help teams deliver software rapidly, reliably and responsibly. ARA tools achieve a key DevOps goal of implementing continuous delivery with several, very quick releases.

ARA is more than just software deployment automation – it deploys applications using structured release automation techniques that allow for an increase in visibility for the whole team. It combines workload automation and release management tools as they relate to release packages, as well as movement through different environment within the DevOps pipeline. ARA tools help regulate deployments, how environments are created and deployed, and how and when releases are deployed.

It is important to assess your Program Portfolio context from an Release Automation perspective to see what is feasible. Ideal state would be to achieve a mature application release automation process and culture.

Gartner and Forrester have published lists of ARA tools in their ARA Magic Quadrant and Wave reports respectively. All ARA solutions must include capabilities in automation, environment modeling, and release coordination. Additionally, the solution must provide this functionality without reliance on other tools.

Release can then be used to validate the release in multiple environments, for example development (DEV), quality assurance (Q&A), and production (PROD).

In the DEV environment, we include functional testing using mocked up third party dependencies. In the Q&A environment, we do integration testing using a production-like environment. In the PROD environment, we deploy the validated release to production.

You can test every build, or enable batching and pick only the latest build.

 

Separate Microservice pipelines

With microservices you can even go further by treating the user interface (UI) and the back end service as separate microservices.

The user interface and the back-end are build and validated against mocked dependencies independently. Once both are validated, the environments can be integrated and validated together.

 

Key principles

• Think of every checkin as production ready!
  Remove the idea of hot fixing and associated complexities. We like to think of this as “fix forward thinking”.
• Keep first level of testing fast and efficient!
  Ensure that your developers never end up waiting. There are different approaches for optimizing your tests
  • Run tests in parallel
  • Throw more hardware at it
  • Keep tests light-weight and avoid dependencies on external service
  • Use mocks (for guidance, read using stubs to isolate parts of your application from each other for unit testing)
• Move long-running tests to a second level of testing!
  Ensure that your pipeline is not blocked by long-running and time-consuming tests. One way to do this is to setup multiple parallel environments in Release Management, which are triggered when a CI build completes.
• Test in production!