Let me explain my need:

I'm having a networked environment with 3 computers connected to a server which will be running full-time. The server also runs a FTP server. I would like to create an environment where 3 developers will be able to work on the same project.

For example, if I'm creating a CRM app, I would like to split the project into modules so that each one will be working on each module like Developer A will be working on authentication, Developer B will be working on saving/retrieving data and Developer C will be working on User Interface programming.

If I use Revision Control, can anyone please guide how to set it up ?

Can the development of the entire app run simultaneously since each of the developers will be working on different areas ?

How can I create such type of multi-developer iOS environment ?

  • Are you saying you want three developers to be accessing the same device? I don't think that's possible, but you could easily set up a central repository and have all three with their own devices (please clarify if that's what you're asking for?) – Dean Harding Feb 28 '11 at 7:57
  • I meant the 3 developers will have access to the File/FTP server. – Mithun John Jacob Feb 28 '11 at 7:59

Sounds like a standard continuous integration setup

It seems that you would like to create a continuous integration environment so that developers can work independently of each other, but merge their work on a regular basis (every couple of hours) and have the final outcome pushed out to the iOS device that acts as the current release standard.

Setting up a version control system

First set up a version control system. Ask your developers which they'd prefer but the hot candidates will be Subversion, Mercurial or Git. The last two offer distributed version control so your developers can work anywhere (even when offline from the main version control server). The first (SVN) requires that a version control server is available for checkins, normally the case when you're in the office. Current versions of Xcode have native support for Subversion, but there is also the Versions client and Git Tower for git.

There is no shortage of blogs regarding setting up any of the above so just choose and get started. Personally, Mercurial is a breeze but your mileage may vary.

Setting up Hudson

Hudson is a very straightforward continuous integration build server. (Jenkins is the direct successor project to Hudson and you may want to apply this approach using Jenkins instead).

Set up Hudson for iOS builds and give it a build target something like this

xcodebuild -project Myproj.xcodeproj -target MyProj -configuration Debug

Configure Hudson/Jenkins to build on every change to the version control system.

The overall process then becomes

  1. Developer A writes some code, tests it locally and checks it in
  2. Developer B simultaneously writes some code and checks it in
  3. Source control merges changes against the latest version
  4. Hudson checks out the current latest version and attempts a build
  5. If the build fails, all developers get an email stating what's caused the failure
  6. Developers work to fix the integration issue
  7. Rinse and repeat until application can be released
  8. Verify that the application works on the target iOS devices, push back as a bug if it fails
  • @Graham Lee Good editing :-) – Gary Rowe Feb 28 '11 at 10:26
  • Thank you very much. I will put into action first and will get back. – Mithun John Jacob Mar 2 '11 at 5:07

It's really no different from any other multi-developer software project:

The server runs version control software, where the merged development project is stored.

On the client SVN is integrated into Xcode 3 and the next version of Xcode integrates Git as well, making them somewhat easier than other options, but you can run a separate Git or Mercurial or whatever client as well.

Someone creates the initial project on one of the client systems and checks it into the server, then the other devs clone copies for their individual machines. They write their pieces of code and build & debug on their own systems. Periodically (at least daily, ideally) the devs check in their changes and the entire project is built and run, as well as downloading changes from the other devs.

At some point you call it done. :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.