Projects Fitting into Planned Release Cycles
Oct 16, 2013
Projects that are run outside of managed release cycle windows, tend to be more focused on getting deployed in production more so than minimizing impacts to other areas of the business. With businesses now having teams in multiple locations and time zones a change can now be more disruptive than ever, as a result of trying to mitigate disruption to business units there is an increasing reliance on projects being required to fit into Release cycles and being subject to the checks and balances that come along with this delivery approach.
with fixed deployment windows provide certainty across business units in regards to when disruptions to BAU are most likely to occur. The financial and human cost of having resources on-call more often is also something businesses are keen to avoid.
As application changes grow more complex and with greater impact on multiple applications there is a need for more orchestration in order to not break other systems or applications. Projects on their own can often overlook full regression testing due to not having the funds to perform it or by ignoring regression as low risk in the interests of being deployed sooner and cheaper. Short of having mature DevOps processes in place, it is essential projects are subjected to strong Release Management governance and regression testing cycles before they are deployed.
If projects avoid being part of a managed release they may be able to avoid costs that come with the regulation and scrutiny that being part of a managed release creates. Allowing projects to behaviour like this is likely to result in the business paying higher development costs, either by a higher number of production defects or by costs passing onto another project.
Having all projects in a managed release cycle allow release compliance costs to be split across all projects as well as ensuring project delivery costs are not blown out by poor enterprise release planning.
For more information on release cycles