Let the community know what you think. Share your opinions now!
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).
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.
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?
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.
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
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.
The ability to design processes through a graphical interface that allows parallel processing, I think that is their greatest strength
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
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! )
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.
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?
You must be clear about differents platforms you have. Every one imposes differents challenges.
Need to check with release management solution, how is fit with your environment like cost and complexity point of way.
If it does what you need and how much it will cost to get it work.