Manage Learn to apply best practices and optimize your operations.

Enterprise release management: The top 10 myths

2/11

Think one size fits all in release management? Wrong!

Source:  Thinkstock/Getty Images

"We need one process for all release management!" is the guiding principle of so many organizations that are trying to implement a modern release-management infrastructure. The reality is that there need to be many processes.

There might be one main high-level release management process that defines the major milestones that we measure our progress against. We could call that a macro milestone process.

Still, there have to be many minor release processes that accommodate the various factors that guide each development team -- such as its technology, time-to-market pressures, risk aversion, development methodology and project complexity. These can be called micro milestone processes.

Let us not forget we need an emergency release process for those patches that have to be fast-tracked through the system.

View All Photo Stories

Join the conversation

4 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

This first myth is in the perfect place. Every form of management - from people to requirements, development to operations - requires agility to work within the organization framework you will be operating under. Many try to apply a formula; the focus should be ensuring the team is committed to the practice, and understand the reduction of risk and cost, and improvement on delivery. Working in the cloud makes this practice more easily managed, if not more important.


James Watson
http://www.jameswatson.info/
Cancel
Great take on this issue!
Cancel
"One size" and standardization are not quite the same. DevOps team may and should have a standard approach, process rules, and a toolset. If each project would budget building their own DevOps process that would be a significant raise of expenses organization-wide.
Cancel
I think this is right.  If you can deploy in minutes, you may be able to deploy daily, if it takes hours, maybe you do it weekly.  I think the context will drive what release practices make since for each product you have to deploy.
Cancel

-ADS BY GOOGLE

SearchMicroservices

TheServerSide.com

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

DevOpsAgenda

Close