Agile operations paired with DevOps teams have changed the game for app development and what users expect out of their programs. Traditionally, software projects would take months or years to build and release. Because changes were expensive and time-consuming, users would often be stuck with initial available functionality – or lack thereof – until a brand new version came out.
With the explosion of mobile devices, however, it was obvious that these intensive development processes were going to have to change. If an app doesn’t perform as it’s meant to, users expect that it will be fixed right away, something that wasn’t possible under waterfall methodologies. QA management must ensure that programs are sufficiently tested and are ready to roll out on tight deadlines. The trick here is to verify that new code is ready to go on a consistent basis, but to not bite off more than you can chew. Let’s take a closer look at how often DevOps teams should release their software updates.
Plan in advance
Software developers and testers should always be looking forward rather than just focusing on the current tasks at hand. While project progress is important, it’s essential to have a long-term roadmap in mind for what functionality will need to be added. Savvy Apps noted that two to four updates should be planned in advance; however, these updates will need to be kept in line with market demands. The plan will need to be revised according to user needs, but it can be as simple as reprioritizing and shifting around items for each sprint. Retrospective meetings before and after each sprint will be critical to understanding what should be focused on and what can wait.
“Continue to balance adding features and stabilizing your app,” Savvy Apps stated. “Stay disciplined and avoid app scope creep. With this approach, you’ll ultimately put yourself in the best position to have a healthy set of updates flowing to your userbase.”
Keep a balance
When a team retires legacy processes and transitions to agile, it is easy to become overwhelmed by the number of necessary changes and the new speed of development. Telegraph Hill noted that organizations might move from annual to daily releases, but this must be done progressively. It will be important to have the right balance of projects and updates to ensure that teams can meet deadlines and still have time to go through agile testing methodologies.
The best compromise will likely be to release one to four updates a month. These can include new features, defect mitigation and other necessary additions. Feature updates should take no more than two weeks to complete, providing time to work on backlog items. When planning out the team’s release plans, it will be critical to balance faster bug fixes with longer feature updates. This will take some pressure off development teams and help improve overall quality.
Release early and often
A general rule of thumb for any agile team is to release updates as early and as often as possible. This will provide a rapid feedback loop about what users want and will get updates into customers’ hands faster. DevOps teams can track user behavior and utilize customer evaluations to determine what areas still need work. With this information on hand, teams can manage defect trends and start planning for their next release.
The art of continuous delivery can be difficult without the right tools, like automation. By using automated tools and continuous integration, teams will not only be able to ensure that new code won’t break the existing build, but that it will be pushed out on time. Any failures will instantly notify testers and developers to deter bugs from being released into production. Automation will help teams live up to their update plans, while streamlining processes like testing and deployment to deliver a quality app as soon as possible.
“As software developers, release should be the highlight of our innovation cycle,” Atlassian stated. “We get to see customers interact with the code we’ve written and provide feedback. Yay! Making releases a natural part of your workday makes it easier to get code out to production and enjoy the satisfaction of saying: ‘That’s my code!'”