I’m a big fan of Continuous Integration/Continuous Delivery. Continuous Integration gives us more confidence in our code by helping us to identify bugs earlier in the development lifecycle. With Software Maintenance representing up to 90% of the total cost of ownership for software, the sooner a bug is found in the process the less frustration, time, and energy that will be needed to fix the bug. This can have any number of downstream effects including purposefully or inadvertently creating code that works around or becomes dependent upon the bug.
Continuous Integration also encourages us to check in early and check in often. Checking in early and often helps us decrease the surface area of our change, thus decreasing the amount of code that can introduce bugs in the system. Checking in early and check in often becomes even more effective when it’s coupled with unit/behavior tests. Having unit/behavior tests allow us to ensure consistency in functionality and behavior across changes. It gives us the confidence that our change, no matter how small, hasn’t changed the behavior of the system. It also allows us to ensure that previous bug fixes and features continue to work as designed. Most importantly, having tests allows you to identify areas of the code that can be cleaned up, refactored, or just don’t behave as expected.
So you may be asking yourself what all this has to do with automating builds for AndroidTM applications. Strictly speaking automating Android application builds consists of: