When evaluating Release Automation, what aspect do you think is the most important to look for?


Let the community know what you think. Share your opinions now!

ITCS user
1414 Answers

author avatar

The only thing anyone should be concerned about when automating releases (this is release automation, not deploy automation) is being able to automatically satisfy audit and control requirements (e.g. auto populate an RFC with necessary certifications from build, test, deploy, and monitor tools). Secondary to that, ability to allow phased adoption, for app teams who may build/support tightly coupled, monolithic, or heavy dependent apps). Remember, the whole concept of "release" goes away when you have achieved the devops model - you will deploy several times a day and the old release orchestration is obsolete).

author avatar

release automation is part of your DevOps toolchain.
First question: what do you want to release and on what platform? Are there solutions on the market or not?
Does the solution fit in your Devops toolchain?
How do you Orchestrate your release automation as part of your DevOps.

I personally think that the business case and the functional requirements are fairly obvious and easy.
Question is at the implementation level.
Is it releasing JAVA, .NET, COBOL (on mainframe...), SAP or what?
What you finally need to release will limit your options.

author avatar

1. Does it support releasing apps on existing platforms and infrastructure (not having to provision every time)
2. Can the deployment design be done agnostic to cloud and platforms so I could deploy my QA instance on-premise and production on Cloud?
3. Does it allow me to pick a Infra/platform service from my IT/Cloud provider's catalog?
4. Is it open architecturally? Can I plugin my own scripts and tools easily?

author avatar

Connects to your current product investments both Open Source and Commercial
Has scalability (No scripting or building workflows)
Includes reporting an analytics
Is a leader confirmed by Gartner and Forrester

I'd explore XebiaLabs. Best solution for the money.

author avatar

It's all about how much you can get Out of the Box in the solution that you are inspecting:
where you need to tailor made your own needs or script your actions to deploy processes
Dashboards and Visualization come and go but the main functions of the solutions needs to be all about Delivery applicaiton to Environement First

author avatar

1. Loose coupled integration with existing build, test and deploy tooling, including platforms
2. Starting form your current way-of-working, introducing an orchestration tool (handling multiple pipelines, role authorizations, notifications) with the possibility to mix manual and automated tasks. And then, from here onwards step-by-step replace the manual tasks by automated ones.
3. Try to avoid a "spagetti" configuration of multiple scripts in multiple tools in multiple languages.
4. No big bang introduction, start small and learn.

author avatar

The ability to design processes through a graphical interface that allows parallel processing, I think that is their greatest strength

author avatar
Real User

1) Check for product compatibility with your existing infrastructure
2) Check how well the product integrates with your middle ware environment
3) Preferably do multiple POC's to figure out functionality, ease of use, how complex it'll be to install/configure, how well do it work with your environment overall. Some tools work better with .Net vs Java - mobile could have potential impact
4) How well does the tool fit and integrate with the rest of your environment, especially for DevOps
5) There are many tools out there so start by looking at the Magic Quadrant and see what sets the leaders apart from followers. Work your way down in products based on cost, requirements, complexity

author avatar
Real User

When I see this question, something popped up in my mind:
1. What is your company's expectation from automation including budget, time and scope.
2. tools selection base on your company's need
3. architecture/infrastucture base on your company's need
4. Which departments should be involved?
5. Current company culture supports this change or not? If not, how to train the company to use the release automation correctly and efficiently?
6. Metrics that shows this project is successful or valuable

And base on my experience, most of the companies when they started the release automation, they do not know the exactly answers of those questions.

So what I did is started from a small project and work with a team, create the pipeline for them and show them what happened and what should we do. Involved the departments in and trigger their interest to understand how they can benefit from it.

So when I make the demo, I use the free tools such as jenkins. The costs is server. We use AWS. Wrote your scripts, create the pipeline to show them how to release automatically, what these reports mean.(Yes, not everybody can understand the report/result! )

author avatar

The tool or product has a decent support group. Seriously no matter how well the software is built you will find some use case they did not document. TeamCity was amazing in this aspect.

author avatar

1. Does it manage software only, or does it provide complete infrastructure/platform/code deployments and undeployments?
2. Is it easy to integrate with your existing tools?
3. Does it provide any advanced capabilities such as continuous delivery/deployment options, automated stage gates, embracing existing 3rd party application/infrastructure content, etc?

author avatar
Real User

You must be clear about differents platforms you have. Every one imposes differents challenges.

author avatar
Top 20MSP

Need to check with release management solution, how is fit with your environment like cost and complexity point of way.

author avatar

If it does what you need and how much it will cost to get it work.

Find out what your peers are saying about Microsoft, Red Hat, GitLab and others in Release Automation. Updated: June 2021.
521,817 professionals have used our research since 2012.