In my last post, I identified a number of areas that make developing iPhone applications with teams problematic and sometimes difficult. In this post, I’m going to present some of my ideas on how to make it easier.
- Use source control. While this may seem obvious to most developers, there are certain aspects of development that people aren’t putting under source control. This includes, mobile provisioning files, certificates, and private keys. I’ll expand on these items later.
- Give all developers the team agent credentials. Teams should designate one member to deal with provisioning (add devices and generate mobile provisioning files), but there may be a time when another developer needs to do it (someone is sick or has gone home for the day). This can be a security risk, but until Apple allows admin users in the provisioning portal to do everything that an admin user can do, this is absolutely necessary.
- Each developer should create a separate developer certificate. While the developers should have team agent credentials, each developer should have his/her own account associated with the team. This will allow the developer to create a certificate and install the development builds on a device. I wrote about the process of generating multiple certificates with one private key which is important for developers working on multiple projects.
- Check the distribution private key and certificate into source control. One of the steps in distributing an application either via AdHoc or AppStore is to create a certificate signing request for the company, upload it to the provisioning portal and then generate a certificate. After this has been done, the certificate and private key (exported as a .p12 file) should be checked into source control so that all developers can install the key and potentially generate AdHoc or AppStore builds.
- Create a build script. Use bash or another shell to create a script that checks out the source code and builds the app. For extra credit, have the build script generate a .ipa file to easily distribute the app and then zip it up along with the mobile provisioning file. In addition, I have my scripts zip up the app and the dSYM file and place it in the source tree (I only checkin the AppStore builds as we generally have a lot of AdHoc releases). This allows any developer to analyze the dSYM file in case of a crash. My scripts name the output files using the svn revision and a timestamp to keep things straight. Lately I’ve modified my scripts to allow a developer to specify the trunk, a specific revision, or a specific tag. In theory, anyone can generate a build with no special knowledge.
- Be careful with source control. This isn’t specific to iPhone development and applies equally as well for other types of development. When I start work each day or after a break in the day, I try to remember to update my source code. In addition, I always make sure I checkin my code at the end of the day. In addition, I check in groups of files at a time and avoid doing huge checkins as the more files I touch, the more chance of having a conflict with another developer’s changes. I use Versions for a visual Subversion tool. This makes it easy to see what files I’ve changed and then before I check in my changes, I diff the files to see everything that I’m checking in. I have Versions setup to use Changes to make it easier to compare the files. It does take more time to checkin my changes, but this gives me an additional opportunity to review my changes. If I try to submit and there is a conflict, I carefully review the conflicts.
- Use instant messaging. I’ve been working from home for 11 years now, so I’ve been remote on just about every project I’ve done. I use instant messaging with other developers, our QA, and my project manager. While sometimes it is easier to call, a quick instant message is very valuable in collabarating. It allows be to bounce ideas off other developers and get more information on bugs from QA.
These are just some of my ideas; I’m sure I’ll have more and I’m sure not everyone will agree with them. My hope is that these ideas will help me work better on teams.
Feel free to comment and leave your own ideas for team development.