How Integrated Builds, package and deploy process helps to increase overall SDLC productivity…..
Often I see questions, how does good config management help for better productivity or bad config management kills productivity? is there any metrics around that? where do I stand? what should I watch out for?
Here are some common key performance indicators that could help you to review the health of software configuration, build and release management for an integrated development environment.
High build cycle time….. On an ideal condition for a 900KLOC C# code, complete product compilation can be accomplished in less than 15 minutes with an ordinary build machine….another 20 minutes to package & deploy to a few boxes…..
One more level finer, how long does it take you to?
- Generate a candidate build from development environment? Are you experiencing more and often compilation failure? Especially while integrating the code?
- Get it packaged according to the product deployment plan?
- Get those bits deployed on the development environment for initial testing?
High build rollout time to QA – typically how long does it take you to promote a build to different environments? a day or more?
Considering candidate build generation is 15 minutes, an efficient build rollout can happen as quickly as 1 hour to any testing environment…..and to as many as 50 tester workstations….
- Where do you get stuck? Environment maintenance? More people cook in your kitchen? do people directly manipulate things on the deployed environment rather than maintaining a source controlled version??
- Do you manually double click the .msi and install on every box?
- When you promote the same build to higher environments, should you manually touch up the application configuration parameters according to the environment? Meaning, for dev x=50, for test x=900, how that change is being handled? Manually?
- Do you manually configure your application?
- Release coordination consumes more time to get a candidate build to be promoted to the next level? Possibly due to late integration…check problem #1.
- Have you defined entry and exit criteria for a build?
How many $$$ do you spend for configuration/build/release management? 100+ hrs for a build rollout? (Possibly because manual build/package/deploy process…. Consumes a lot of time from different roles from release coordinator, build engineer, DBA etc…)
In an ideal world, it need not be more than 2 hrs/per build rollout, may be 5 hrs….
If not…. Here are the problem indicators:
- Manual build/package/deploy
- Manual coordination with external teams like DBA…
- No defined entry/exit criteria..
If your shop is experiencing few or some of the above mentioned challenges…. Certainly there are ways to improve your overall config, build and release management process for an integrated development environment…..get ready to with the following solutions..
Implement Continuous Integration
Many shops still integrate code in an old fashion – say, on a 6 weeks development cycle, 4 weeks independent development (only local builds) and last 2 weeks for integration….typically late integration fakes the progress… lot of hidden tigers will appear when you start to integrate….
If your SCM tool doesn’t support frequent integration, worth considering a switch over to a tool like TFS which supports CI builds out of box….
Do you integrate continuously? NO? are you panic about the frequent changes on your foundational code base..?
Please consider implementing continuous integration – great ways to make sure a code change works well with all others and enables you to test the change immediately in next 30 minutes by efficient build/package/deploy automation…..
Unattended Build/package/deploy process
- Efficiently automate the build
- Coach the team in such a way that “build break is a crime” – it should get immediate attention and action…
If it’s manual – that certainly hinder your progress… automate the builds… almost all the tools available in the market have the ability for continuous integration and automated build process…. Make sure compiles assembly is ready for testing at the earliest after the change…..
- Automate the packaging process
- Tightly integrate it along with build process – build process should automatically trigger the packaging..
- Maintain centralized packaging scripts – otherwise you will end up packaging some MS Windows assemblies along with your package.. 😉
- Keep it simple and fast… say, if .vdproj takes more time to package something… consider trying a PoC with WiX – in my experience WiX has helped us in reducing the size, time and it’s so flexible….
Automated and integrated packaging process can really boost your dev team productivity.
Consider the current packaging model to be manual… post build, the build server sends out an e-mail… build engineer has to manually copy the assemblies to some location and kick start the packaging process. By the way, he/she might accidently forget some assembly while copying or xcopy might simply fail for an assembly which we did not notice…. the .msi generated off of the manual process certainly fakes the testing… and manual process could be more time consuming as well….
Deploy and post deploy:
- Automate the deploy process – there are plenty of easy tools available like psExec, WinRs, PowerShell scripts etc….
- Integrate deploy with build/package process…. This is awesome to have… if a developer wants to test a code change….he just have to click a button to Q the build on the build server… then it should build->package->deploy off of 1 central id…this gives another ability for you to restrict all other people from accessing the application servers too… so the environment is so clean….
- Establish a process to have an “operational application with bare minimum functionality’ at the end of each business day – create another automated build for the end of each day which deploys the latest bits to the environment
- Establish a build verification test processes
- If possible automate BVT too… sometimes; BVT might be a killer… daily executing some test cases for hrs might irritate the development community…..
Finally make some changes to Source Control too…..
- Envision the source tree structure in such a way that helps rapid development cycle
- Define efficient check in policies defined to avoid code duplication, confirm unit testing, make sure review process etc..
- If your team often breaks builds….consider creating some tiny tools to mimic exactly what happens on the build server…like take the latest & build everything locally in a fashion how that happens on the build server..Otherwise teams might not be working in the source control and often code integration results in failure…..
Largely, continuous integration, integrated builds, package, deploy process can really boost your overall SDLC productivity….