IT Operations Management (ITOM)

Should you opt for a continuous delivery tool for application release automation?

Should you opt for a continuous delivery tool for application release automation?


group conversation.PNG


Guest post by Alex Savio, Technical Ambassador (HPE Codar)
Hewlett Packard Enterprise

In today’s world, everyone shows interest in solving the problems faced by dev and operations teams. There are many tools available to help the management implement a “DevOps” culture among their workgroup.  These tools offer support right from the beginning; from requirement gathering to managing the deployed application (which are usually day-2 operations). Especially for release automation, there are many tools to deliver continuous delivery and/or deployment features.  But the question remains, does the continuous delivery tool help the developer, tester, or the operations team? (Or, does it help all of the above?)

Here is what various teams around your company might say about DevOps tools:

  • The development team may say, “Why do we need a tool to deploy an application when we already have a script which does the same thing?”
  • The QA team may say that they have automated UI/backend scripts to help them deploy and test the functionality, what is the benefit of using a dedicated continuous delivery tool?
  • The release management team may explain that most of the time they use the scripts owned by dev/ QA and at times they may manually deploy the application and testing the same.
  • The IT operations team might say they can do the deployment manually or through some automated fashion but would need a tool to check whether the dev and QA have executed the regression before releasing it to us.

 This is a good question isn’t it? 

Differing perspectives

Is your company experiencing the see-saw dynamics that can occur between both sides of the app team? In these situations, the development team may complain that they never get to see how Ops folks deploy the application on production. On the other hand, the Ops team may face problems when they roll out an application which is tested across different dev and test lifecycle stages?

Both apps and ops teams may believe the misconception that the continuous delivery tool will only provide deployment automation capability. But, they often ignore the fact that deployment is just a single activity—of many—which are executed during a release process.  An effective suite of DevOps tools is so much more.

How can we solve this perception dilemma? Each of the personas in the DevOps world have their own perspective on solving problems. But not all of the perspectives caters to the actual need of complete or near-perfect release pipeline automation. (They each have perspectives, but not a complete view.) How do we solve this perspective separation? Should it really be solved at all? 

The answer is of course yes. But what is the ROI of solving it? How does solving the separation help DevOps teams who don’t think they have a problem at all from their side?  How does it get solved?

Exploring the factors at play

For an application release there are many factors involved—the deployment of the application across various lifecycle stages starting from dev to production should be consistent. Each of the personas will deploy the application on their environment using the scripts which may work only for that environment or release lifecycle stage.

What happens when the developer’s script cannot be used by the operations engineer who rolls-out the application in production and vice-versa. Another example of this application discrepancy is when the scripts don’t fit in each other’s lifecycle stage. This results in teams ending up maintaining those scripts which are applicable for the respective environment. 

Single blueprint for all teams 

A release automation tool will first solve this problem by providing a common way of deploying an application on different lifecycle stages—especially through a common blueprint. The design helps to stand up a platform or micro services. The architecture of the blueprint may vary from stage to stage, but the method to deploy the application remains the same across all the stages.

A common blueprint will help the DevOps teams perform consistent and successful deployment on all stages. The tool may help the teams to create cloud-agnostic and cloud-native blueprints. The tool may also provide a continuous feedback loop mechanism through ops and dev team communication and collaboration. The tool is a place where they can share each other’s ideas to improvise the deployment and release process—helping to simulate the production environment on all stages.

Another aspect is the “holistic” view of the entire release process. If you have a continuous delivery tool in place, it should bring a complete panoramic view of your entire release process. It also may help you identify the gaps which impact your time to market. Once they get to see each other’s progress they will more likely concentrate on keeping their rack clean before complaining about what is on the other team’s rack. 

Requirements for success

 In general, the continuous delivery tool must integrate with other tools in your ecosystem.  It may even replace one or more tools! Even if it is not replacing any tools, it is still beneficial to establish within your environment.  

It should interact with infrastructure providers, third-party deployment intelligence providers and SCM tools in a secure way. The continuous delivery tool may replace your home-grown scripts or it may allow you to on-board the existing automated deployment scripts—so you don’t need to re-invent the wheel.

Ideally the tool must provide a release statistical KPI’s dashboard, which is used to measure the quality of the release. It will help executives follow the release progression and may forecast the release trends and take appropriate action if it shows bad release KPIs scores. The tool may also report the cost involved in using resources like infrastructure or platform to help the resource manager to calculate the investment versus ROI and help management procure or invest only what is required. 

Another dimension of the continuous delivery tool is having sophisticated APIs. The API helps for integrating the build and continuous delivery tool to perform CI/CD operations. Through CI-CD integrations, the continuous delivery tool will help the developer automatically deploy the application upon code check-in and also takes care of other activities like testing, notification, getting approvals and promoting the application till production. The tool should take care of Day-2 operations, but for resource and app monitoring it may rely on other tools.  Practically, for a stable application rollout and successful application release, a continuous delivery tool is inevitable. In order to automate the release process, a continuous delivery tool with above mentioned qualities is a must-to-have in the midst of Dev and Ops team ecosystem. 

  • cloud management
  • infrastructure management
About the Author



Congratulations on your first blog, Alex.

Interesting perspective and insightful article!!!!

//Add this to "OnDomLoad" event