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.
“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.”
1. Loosely coupled integration with the 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.
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!)
“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.
