Head of Marketing
Continuous Integration. A wonderful concept. Merging all developer working copies of a mobile application code with a shared mainline a number of times a day. The copies are checked, problems are detected early on and easily. However, despite the obvious advantages of such a system, many companies have problems in putting continuous integration into practice effectively. We present here five potential stumbling blocks and ways to effectively prevent them.
Don’t Let Your Build Spiral Out of Control!
Continuous Integration means dealing with a whole lot of new builds and if your build process is not under control as needed you may find yourself with new builds that has new code checked into it by your developers, resulting in your newest build having errors and changes.
In order to avoid this, you can do two things
- Mark and promote a candidate build and perform testing on that build
- Branch the code and then at a certain fixed point carry out new development on that branch.
Although the latter adds a bit of overhead due to the need to merge the project branch back into the master on occasion, control tools can lessen the pain of merges.
Treat Problems from the Root!
Continuous Integration includes carrying out unit tests (that test isolated components), integration tests (that test the way components integrate with each other) and possibly acceptance tests (high-level tests that are customer understandable). The higher level a test, the more likely that it will fail.
If the value of the tests starts to be negative in your teams’ eyes with talk of ignoring failures, not figuring out why their failing or how to make them successful you need to STOP. Fix the issue by finding the root cause and fixing it. If it can’t be prevented, the test is no good. An excellent way to deal with a failing test is to separate it into smaller tests and deal with each, step by step.
Continuous Integration of mobile application development projects builds often start out speedy but with time become more complex and before you know it, you can find yourself with a build that takes several hours (in comparison to the several minutes it originally took)! With drawn-out tests the problem is that is something goes haywire along the way, it will take not hours but days to check that the tests passed. In a high-pressure environment this is a recipe for disaster.
Take care as far as your build time is concerned. For slow-running tests consider overnight end-to-end runs or running tests in parallel. As far as automated GUI checks are concerned, consider if they are truly valuable as part of the build process (such as fast verifications that always succeed).
Exploratory Testing is your Friend!
One may assume that after carrying out the acceptance tests part of Continuous Integration that your mobile application’s code should be ready for deployment. That simply isnâ€™t the case. Bugs could still very well be lurking.
Passing acceptance tests should be equated with being ready for acceptance by testers. Exploratory manual testing should be the next stage so that those pesky bugs can be plucked out in the magnificent way that only human testers can pluck them out. Automated testing should be considered one side of the mobile application development coin- exploratory manual testing is the other side of the same coin.
On the Same Wavelength?
Suddenly, you realize that your remote team has a different understanding of what unit tests- they think that unit tests are what your local group refers to as “integration tests”. No problems with the code but false errors are getting sent to the local team who spend precious time trying to get to the bottom of a non-existent problem. Oh dear.
A distributed Continuous Integration setup is fine- just make sure that your teams are on the same wavelength and have the a joint understanding of the commit and build rules.
Continuous Integration in the production of mobile applications doesn’t start and end at setting up the system. Far from it. The real challenge is keeping the Continuous Integration process running smoothly over time as it grows and grows. The daily build challenge that we’ve dealt with for years is even larger once Continuous Integration stepped onto the scene. Just remember- you want to keep it as repeatable, fast and simple as possible.