What are the fundamental building blocks of successful ARA?
Application Release Automation, or ARA, is the consistent, repeatable and auditable process of packaging and deploying an application or update of an application from development, across various environments, and ultimately to production.
Successful ARA eliminates the need to build and maintain custom scripts for application deployments, while simultaneously reducing configuration errors and downtime. By providing a model-based approach to performing critical automation tasks, it effectively increases the speed to market associated with agile development and gives stakeholders the ability to coordinate and automate releases between multiple groups and people.
In this article, we’re going to take a look at the five fundamental aspects that make up application release automation and talk about how each one serves a critical role in ARA’s success.
The first tenet of ARA is packaging. Packaging is just what it sounds like – taking a bunch of parts and pieces and bundling them up together in a manageable and functional way. So why is this important and how does it fit within the context of Application Release Automation?
Consider the following example: You and your company decide to switch offices, from your current building to one just down the street. You hire a couple of movers, get them in, and tell them you want to take all the stuff in your office and move it to the new location. Easy enough, right? So the movers start grabbing chairs, desks, computers – everything – and carrying them down the street. They’re throwing things out the door, through the windows, everywhere! Next thing you know, a few chairs are broken. A laptop is missing. Your iPhone is gone! The movers say, “Hey, look, those chairs were already broken. I didn’t see any laptop on the table…” In this scenario, there is no bill of materials – just a bunch of confusion and some missing and broken parts. That is where packaging comes in.
Packaging creates the bill of materials for your deployment. It is your way of knowing exactly what you need to move from point A to point B. You take all the pieces of your release and wrap them up neatly so they are ready to ship. It’s the method by which you can assure that everything that was supposed to make the move, in fact, did. Packaging allows you to confidently say that what you had at the source location is what ended up at the target location – and it is critical to a successful ARA process.
Dependencies are another critical cog in the ARA process. When you are working on your release, you need to understand what other applications or components are involved for its success. For example, your web application uses a database hosted on a different server. If the data in that database is changed, or columns are created or deleted, how will that impact your application’s functionality? This is a dependency – the way your application functions is dependent on the data in another location.
In the case where you are pushing out an update to an existing application, you need to also take a look at how other things might have relied on the old application. Are you doing away with a feature or function that is going to have an impact on something else? This highlights how you need to not only examine what your application relies on to function, but also the mirrored function – what outside processes and/or applications might depend on your existing app.
As you can imagine, the process of charting dependencies can grow exponentially. If application A depends on databases B and C, and C depends on D, E and F and then F… you get the idea. It can get very big, very quickly. This is why it is helpful to chart dependencies as you move, so you have a dependency map that is up-to-date and adaptable. You know where the dependencies are, how and what your updates or releases will affect them, and what you need to keep an eye on post-deployment. If you start charting dependencies at the beginning of your development, it will make ARA much easier down the road.
Promotion in the context of Application Release Automation is the process of moving the application or update from one stakeholder to the next so that the release is as close to perfect as possible before it is deployed.
This is a crucial step in the ARA process because it creates an audit trail that assures that the right people along the way gave this deployment the “OK” to move forward. Getting the input from multiple parties is imperative to a deployment’s success because each party – from the developers to release engineers to the Quality Assurance (QA) team – has a different perspective. For example, developers are looking at an application and saying, “How can I make this the best application possible with the most robust set of features?” While someone on the QA Team says, “How can I break this?” They are running your application through tests, wringing out inefficiencies and errors along the way.
By passing (or promoting) your release through the chain of stakeholders, you can find the holes in your release before the customer does.
Deployment is the act of launching your application and from point A to point B. Using the word “launch” is no mistake – it’s just like the commander of a space operation pushing the launch key. It’s pressing one (or maybe a few) buttons and releasing your application or update, configuring its operating settings, and letting it out into the wild. Deployment is making sure the release makes it to its destination safely. At its core, this is the fruit of the labors of ARA – letting your deployment free to do what it was designed to do! The core objective here is that ARA moves this from a scripted, expert level process to a more model-driven perspective (where less skilled resources can understand and perform the deployments…). So when applications, components, and dependencies are modeled within an ARA solution, companies now have the means to deploy their critical applications without having to rely on the superhuman resources who designed and built the application.
Another key aspect of Application Release Automation is compliance. This is literally, “Are you following the rules of the game?” However, the rules of compliance vary wildly within different environments. At a small startup, with a team of three people making a web app – there are probably not too many rules to follow. The compliance necessary for a game launching birds at disgruntled pigs is minimal.
At the other end of the spectrum are things like banking and government applications. Here, there are laundry lists of rules and regulations that need to be strictly obeyed or you may find your application being tossed – or find yourself in a CIA interrogation room (ok, we haven’t heard about that actually happening…but you can imagine!). With compliance, it can be helpful to start by asking yourself, “What do I really need here?” Once you figure out the requirements that are necessary for your specific application, you can map them out and discover what tools you can use to solve the problem.
This is an essential key to ARA because if you have four out of the five steps above, but miss on compliance, all your work was a waste because it’s not going to play nice in its environment. Adhering to compliance – and documenting that you did – is crucial to successful ARA.
With a strong understanding of these five key building blocks, you will have a solid base to start exploring the wonderful world of Application Release Automation. Go forth…and automate!
About the Author/ Wesley Pullen
Wesley Pullen is the general manager and vice president of deployment solutions at Electric Cloud. Pullen leads the Release and Deployment business at Electric Cloud and is responsible for go-to-market strategy to aid in the company’s growth and expansion efforts around DevOps, Continuous Delivery and Deployment. He brings more than 18 years of experience in software development methodologies and design standards, applying this experience to both commercial and private sectors. Linked in: https://www.linkedin.com/in/wgpullen Twitter: @WesleyGPullen