At IT Central Station, 2,722 users follow the release automation category -- which includes product reviews and questions published by enterprise tech professionals.
Since the beginning of 2017, our release automation reviews have been viewed over 74,850 times.
Our users discuss and provide expert feedback on various criteria, such as:
Scalability
Reducing Downtime
Deployment Capabilities
Workload Balance
Length of Release Cycles
Most recently, our users engaged in a discussion about choosing a release automation tool:
Read the full Q&A here.
What Do Users Look for in a Release Automation Tool?
Lidor Gerstel, DevOps Engineer at a Comms Service Provider with 501-1,000 employees:
“It's all about how much you can get out-of-the-box in the solution that you are inspecting: where you need to cater to your own needs or script your actions to deploy processes.
Dashboards and visualization come and go, but the main functions of the solutions need to be all about application delivery to environment first.”
AHMJ Tromp, Software Development Consultant at a Financial Services Firm with 1,000-5,000 Employees:
1. Loosely coupled integration with existing build, test and deploy tooling, including platforms.
2. Starting from 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 "spaghetti" configuration of multiple scripts in multiple tools in multiple languages.
4. No big bang introduction, start small and learn.
Michelle XIE, Automation Test Developer at a Software R&D company with 51-200 employees:
1. What is your company's expectation from automation including budget, time and scope?
2. Tools selection based on your company's needs.
3. Architecture/Infrastructure based on your company's needs.
4. Which departments should be involved?
5. Does current company culture support this change or not? If not, how to train the company to use the release automation correctly and efficiently?
6. Metrics that shows if this project is successful or valuable
And based on my experience, most companies (when they started the release automation), do not know the exact answers to these questions.
So, what I did is: started from a small project and worked with a team, created the pipeline for them, and show them what happened and what we should do. Involved the departments, and trigger their interest to understand how they can benefit from it.
So when I run the demo, I use the free tools such as Jenkins. The [only] cost is the server. We use AWS; Write your scripts, create the pipeline to show them how to release automatically; What these reports mean (Yes, not everybody can understand the report/result!)
A Software Development Senior Manager at a Software R&D company with 1,001-5,000 employees:
“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.”
Read more user feedback on release automation tools.
I'm naturally biased as the CEO of a Release Automation technology company.
However, the most common advice I try to give in the market is to find a technology that's scalable, provides standardized release pipeline templates across any underlying architecture and is maintenance free.
I offer a commercial tool built specifically for enterprise requirements including reporting, dual-mode interface and infinite scalability from Mainframe to Docker.
What I see most common in the market is script-based or workflow-based open source tools used for release automation. While this can work for a handful of applications, once you get to the critical mass of 25 or more applications, this approach simply does not scale. And who wants to write and maintain all of that plumbing code?
Commercial release automation tools are fully supported, include all of the requirements for the enterprise, require no scripting and are far less expensive than taking a people-centric open source approach that does not scale.
Hope this helps.