If you didn’t make it to Dreamforce ’12 in September, or were unable to attend my Team Development on the Force.com Platform session, you can now watch it on YouTube
Team development is an essential concept in any large development effort. This is as true for developing on the Force.com platform as it is for any other. But how do you support team development using enterprise best practices in the Cloud? Join us to learn the strategies that will help your teams increase their productivity by helping them coordinate more effectively and leverage powerful practices to complete your projects faster. This is a pragmatic session that will help you and your teams become more productive. Bring your team members, your challenges, and your questions.
Rick, do you have other notes listing the pros-and-cons of having Integration, QA, and FC Sandboxes? Specifically I’m looking for a list of risks and benefits. You admit in your slides (when introducing the FC sandbox) that it’s more complex, but the presentation doesn’t elaborate on the compelling advantages of the added complexity or the looming risks of developing without it.
Tom, that’s an excellent question. Thanks for asking. Here is some initial thinking, please feel free to add to and enhance this list:
Advantages
* Clear ownership of each sandbox.
* Developers are independent of the other teams
* Simplifies coordination between teams
* Practice deployments – avoid/eliminate/reduce unexpected surprises and risks
Disadvantages
* Additional time to migrate and promote code to the various sandboxes
* Additional licensing costs if not using Unlimited Edition
Rick, what do you think the pros and cons might be of using branches rather than tags for release? My bias towards branches is that if something needs to be fixed in-production, I can check-out the branch, make the change, then redeploy the release/branch to production without fear if introducing anything from the trunk OR infecting the trunk with anything from the branch.
Tom, thank you for another good question.
A tag is a way to put a meaningful marker on a code base, as in this is what we shipped in version 2.1. They never change.
A branch is where development is done, as in this is feature XYZ that may or may not ship. Files within a branch can frequently change so merely creating a branch is insufficient to know what is in production, which is extremely important. Read more here: Thou Shall Always Know What is “in” Production
Branches and tags are not mutually exclusive. Most (if not all) source code management systems allow you to create a branch from a tag, allowing you to produce a new branch to address an issue that requires immediate attention (e.g. hot-fix). Once addressed, the branch also needs to be tagged so that you know what is in production.