In this tutorial series we will explore a rarely discussed (but highly valuable) process of
developing software that is disappointingly absent in the iOS and mobile world: Continuous Integration.

In a nutshell, Continuous Integration (CI) allows you to speed up the development and release process by constantly checking the code repository for build issues as well as automating a variety of procedures that you would otherwise have to perform yourself.

After reading this tutorial you will be able to set up from scratch an automated server that will provide all of the above benefits (plus a few more). Specifically, we will cover:

1. The theory behind continuous integration.
2. Installing the Tomcat Apache Webserver. This will be used to run the CI software.
3. Installing Hudson. This is the CI software that will monitor the repository and start the
   build.
4. Writing the bash build script.We will go through the basics of Bash and how to compile our Xcode project from the command line.
5. Extending the build script in various ways, including automated deployment.

Required Knowledge

Although we will go into detail about all aspects of how to set up your CI, it is assumed you have no prior knowledge of server administration, bash scripting, or CI procedures. Having said that, it is expected that you have a general grasp on Xcode and archiving builds, and also that you understand (and have access to) a source control server.

If you are not already at the point where you are using a version control system such as Git or SVN for managing your code, this tutorial will be a little out of your comfort zone. To learn about source control and how it can benefit you, I highly recommend signing up to GitHub. They offer free public repositories and have a great tutorial for new users on how to set up and use Git as a VCS.

Also available in this series:

1. Continuous Integration: Series Introduction
2. Continuous Integration: Tomcat Setup
3. Continuous Integration: Hudson Setup
4. Continuous Integration: Scripting Xcode Builds
5. Continuous Integration: Script Enhancements

What Is Continuous Integration?

As anyone that has worked in a team of developers can attest, managing code repositories and code conflicts can be a huge pain. Developers can spend several hours after a merge managing and cleaning up conflicts.

As well as working with conflicts, manually building apps for testing or enterprise distribution can take a significant amount of time. Someone has to be responsible for keeping their repository up to date, managing the developer certificates and provisioning profiles, archiving the code, and uploading the IPA file to a server for distribution.

Because of the complexities involved in these procedures, developers are sometimes loathe to commit and build their code and will manage to make a build of the full project only once or twice a week.

CI allows the builds to be automatically started after every commit to the repository. This allows errors in the code and conflicts to be easily identified and resolved quickly and effectively.Although this is useful, by far the most useful feature that we can get from setting up a CI server is automating and distributing our builds. Imagine if all you had to do was type svn commit -m "Fixed the customer ID bug" and 30 seconds later the build was sitting on a website waiting to be downloaded by a tester. Setting up a CI can make that happen!

How It Works

For CI to work effectively, developers need to commit early and commit often (at least once a day). The CI server continually polls the repository to check if there has been an update. If it detects a change, it will begin building the project and performing any associated tasks.

If the build is successful, the team is notified of the successful build. If the build is not successful, the team is notified of:

• Who on the team broke the build
• What changes caused the build to break

In the event of a broken build, the team can quickly asses how the build broke and go about resolving the problem, and the problems that need fixing are small and easy to manage because we are committing every day instead of every week.

The Main Advantages Of Continuous Integration

• Problems with the build are identified early.
• Identified problems are usually small issues that are easy to resolve.
• Automated building, signing and distribution of the app saves time.
• Constant access to the 'latest' build for testers.
• Unit tests can be run on every build, allowing developers to detect functional issues as well as compilation errors.

Unit testing is a world onto itself and unfortunately will not be covered in this tutorial. I encourage you to read up about using unit tests as not only part of your CI but a part of your development process.

The Main Disadvantages Of Continuous Integration

CI is certainly not for everyone. It can take a significant amount of time to set up a server for your needs. The CI server software is best installed and set up on a separate machine to that being used for development and the hardware requirements. That means extra costs for hardware.

Next Time

In the next article we’re going to get our hands dirty setting up the Tomcat web server. We’ll cover system requirements, how to install it, and starting/stopping the server. Catch you next time!