The frequency of releasing software varies widely in the industry. There can be good reasons for extended periods between public releases of software, but your development culture or methodology should never be a block. If the test and release process is made as reliable and predictable as possible, then everyone gains. But how do you get started? Jonathan Hickford writes from experience.
How much time does your team spend on tasks that could be automated? How much more effective could your team be?
Releasing is a core part of software delivery, and we should make it a frequent and painless activity. Yes, you might be busy, and it never feels like you have time. But it’s a false economy to keep putting it off.
It’s not always up to the software team though. The business needs to give the software function freedom to improve. And businesses might not understand how to do this, or even that they need to. This is especially true of companies that are not dedicated software companies.
The good news is that there are many companies successfully improving their release process. Here are some tips for starting the change.
#1: Be the change that you want to see.
The way you develop is under your control. Many of the changes that need to occur in order to start automating the release process are within the control of the development team.
- Start reading up. Research best practices, read about approaches that others are taking, and tools that can help with the process.
- Lose coupling. Start thinking about which parts of your application you want to deploy separately. If you can architect these components as distinct products it will help make the transition to deployment automation cleaner.
- Testing. A key part of any release process is the testing. The more testing you can automate the more confident you can be in each release. If the aim is to be able to deploy much faster than the current cycle, you’ll need a testing approach that can keep up.
#2: Get buy in
If you are lucky enough to be in a position to call the shots and implement today then great! However it’s more likely that implementing automated releases is a decision which needs to be taken by a number of people, who will all be impacted by this change.
- Understand who you need to convince. It might be your manager, your customers, the CEO, or the development and operations teams.
- Clarify the problem. Explain how much money is being spent on each release, how many releases need to be rolled back or repeated, how frequently you can currently release vs how often you’re asked to release.
- Show a vision of a solution. Get tools vendors to help you with this, they might be able to help setup a demo or proof of concept.
- Explain the benefits. Explain how you’ll be able to get value to customers faster. That value might be through more frequent feature releases, fewer issues after a release, or reduced downtime for each release.
- Don’t gold plate it. Automating releases isn’t a magic bullet that can fix everything. It’s important that everyone knows what the project is trying to achieve, and what it is not going to tackle.
- Explain ‘mean time to repair’ and ‘mean time between failures’. Automating releases means that you can fix a broken release faster. It will also let you release more frequently. As a result of more frequent releases you may have ‘bad’ releases more often, but as these can be fixed faster, total downtime/impact should be reduced.
- Let them know what you need. Time!
#3: Create a culture of learning
Your release process is something that many members of your team, and other teams, will be involved in. You need buy in from all of them. If you can encourage the sharing of knowledge, then they’ll be helping each other, and doing your job of championing frequent releases for you.
- Lightning talks. These are short five minute presentations that get to the point quickly. Developers, testers, DBAs, support and operations will all likely be impacted (hopefully positively!) by automating releases. It’s important that everyone understands what each team does.
- Code reviews. Catch potential issues earlier and share knowledge among the team. Minimise the number of ‘bad’ releases and try to produce fewer broken builds in your integration environment.
- Don’t do it all yourself. As tempting as it might be to set up the release process yourself, or using a small number of sandboxed developers, it’s important everyone understands how the system works. The last thing you want to happen with the new automated release process is for it to go wrong and you have to wait for a specific person (or you) to fix it.
- Pair programming. Pairing while building and configuring the release process is a great way to ensure that the whole team understand the process. Don’t just restrict it to developers though, involve the test team and anyone else involved in the process.
- Engage the community. There are lots of user groups and conferences that are focused on automation and tools used. DevOps days are a good example where you can hear from many people on the same journey.
#4: Show improvements
The end goal of more frequent ‘push button’ releases to production may be ambitious and feel like a long way away. However automating small parts of the large process have considerable benefits, so start small and iterate quickly.
- The hardest part is starting. The first change will probably be the hardest, and you have to jump through the most hoops, but once the ball is rolling each subsequent change will be easier.
- Proof of concept. Consider making a proof of concept automated release channel, maybe for one application or database between two less critical environments. Having something to demonstrate can help obtain buy in and to test improvements.
- Start small. Even a smallest piece of automaton has value, ask yourself what it the most value that you could add with a single days’ worth of automation effort.
- Repeatability. Picking something that is run regularly, say in development or test environments, will save more time that an infrequent production deployment task. If you can repeat tasks across all environments then even better!
- Demonstrate the improvements. Report back to the business and the team regularly. Track how many tasks have been automated, how many hours have been saved, how many releases have been successfully launched, how regularly you can deploy. Dream about that final demo when you can ask the CEO to push the big red deploy button for the next major release!
- Be prepared to get it wrong. Keep the iterations small, especially at the beginning of the project. Don’t worry it will be quicker and easier the second time round!
#5: Optimize your structure
Only some of the barriers to automating your releases will be technical. It’s likely that small changes to how the release team works with other areas of the business will need small changes too.
- Think about production first. By no means are we suggesting that you automate your production release first! However make sure that the methods and process you create for releasing to other environments can be reused in production. You’re aiming to have a tried and tested deployment mechanism which can deploy a release to a representative production environment, before you press the big red button to deploy to production.
- Get end-to-end working first. An agile approach, where you automate a small slice of your applications release process from development to production is likely to be a better starting step than automating all of your application releases from development to test. This end-to-end approach will uncover potential problems sooner.
- Cross-functional teams. The release process typically involves developers, DBAs and testers. Invest time teaching and learning about what each team needs to do during the release. For example if the test team can deploy their own releases to the test environment, there might be significant time saving for everyone.
- Transparency. Ensure all teams and stakeholders can see what will be automated next, and what changes they may have to make. Let the business know how much time is being saved compared to the deployments of days gone by.
- Co-location. If you’re able to co-locate developers, operations and testers together while automating parts of the process you’ll be able to get through tricky problems faster. Even if you’re only able to do this for a couple of hours a week it will make a positive impact.
- Version your process. Version everything! Make sure you keep your deployment process under version control. As well as the usual benefits of audit, and knowing what changed when, you may need to deploy old versions of your application which require an older build process.
So act today and start thinking about how to automate your release process. There are more tools and expertise that can help achieve this goal than there were a year ago. In a year’s time all night deployments could be a distant memory.
If you're interested in more articles on frequent releasing, you may also find Five Tips for Achieving Continuous Delivery and Automating deployments with the SQL Compare command line interesting.