A look at release management as a critical DevOps function at ManageEngine

The traditional approach:

The waterfall methodology

Back when release management first became a part of ITSM, the waterfall approach was the go-to strategy for deployment. In fact, some of our product teams continue to follow certain aspects of it. The waterfall methodology is a simple linear sequence of events, meaning you don’t start the next stage of the release cycle until the previous stage is completed. Things going into the release are planned upfront—requirements, prototype, designs, etc. The development takes place in a separate branch. After development and unit testing are complete, the code is pushed to the main branch where it’s tested once again and released. Unless any issues occur, the completed feature isn’t touched again.

The problem with the waterfall method is that the time invested in each stage isn’t always equal. We might spend, for example, 30% of the targeted release cycle duration planning. We may not always know exactly what our requirements and expectations are at this stage, so as we build, we figure out what needs to be redeveloped. If we notice flaws or want to tweak features towards the end of the testing stage, we can’t just let a substandard release go live—we’d have to go back to the previous stage. So it’s not always ideal to stick to each stage in a rigid manner.

The waterfall method isn’t commonly followed anymore, but it would be ideal for startups working on a budget or smaller projects with well-defined requirements.

The agile approach

The agile methodology is an incremental approach wherein a release is divided into multiple sprints or iterations. This way, we can deliver quicker and smaller releases with minimal response time to changes and fewer defects. It relies extensively on constant collaboration between product teams and developers. Interestingly, agile software development even has its own manifesto, which is worth a read.

There have been over 50 frameworks developed over the years, the most popular being Scrum, Kanban, Extreme Programming (XP), and Lean. The agile method is suitable for releases with multiple variables or when you need to deliver within a limited time frame.

Agile methodology is commonly preferred over waterfall because it:

• Incorporates changes even late in the development stage.
• Focuses on customer satisfaction.
• Delivers high quality products.
• Reduces unpredictable delays.
• Results in higher ROI.
• Encourages engagement between teams.
• Increases productivity.

DevOps

While the agile approach bridges the gap between product management and development, DevOps goes one step further. DevOps is a set of practices that combines development and IT operations.

It doesn’t have to be agile vs. DevOps. Combining aspects of the agile approach, such as incremental progress, with features of DevOps, like automation, metrics, and cross-disciplinary team collaboration, allows you to deliver quality releases to meet the pace your business requires at lower costs.

CI/CD

Continuous integration (CI), continuous delivery (CD), and continuous deployment are commonly followed practices in DevOps.

Continuous integration:

The practice of merging small code changes into the main code or code repository. Since each team likely has multiple developers working together, CI helps ensure everyone is on the same page. This synchronization occurs frequently, maybe even multiple times a day.

Continuous delivery:

Once a new code is committed, these changes are validated through build and automated tests. CD is an extension of CI where the build changes are deployed into the staging environment for functional and performance testing.

Continuous deployment:

Often used synonymously with delivery, continuous deployment is actually the next step. The difference between the two is the level of automation. With continuous deployment, builds are automatically deployed to the production environment and monitored.

Continuous deployment is out of scope for on-premises products, but it works for cloud solutions if you have the right resources to keep up. For any completed release, there will be some minor issues or enhancements. We have a couple of team members who continue working on the code constantly and they keep pushing it to the release branch. This code will be retested and taken up as part of the subsequent release.

Benefits of CI/CD

• Fixes bugs quickly
• Faster quality releases
• Effective communication between developers
• Faster validation
• Faster troubleshooting during tests