Team Development on the Force.com Platform – Dreamforce ’12

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.

This entry was posted in Dreamforce, Practices, Salesforce.com, Software Development. Bookmark the permalink.

6 Responses to Team Development on the Force.com Platform – Dreamforce ’12

  1. Tom Gagne says:

    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.

    • Rick Ross says:

      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

  2. Tom Gagne says:

    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.

    • Rick Ross says:

      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.

  3. Jack says:

    Hi Rick,

    Can you please explain a team development scenario if everyone is using single developer sandbox for the development and not individual dev orgs. I mean this is what is practical where we have support team supporting a particular force.com app and each developer is assigned to a bug/fix or more than one developer is assigned to particular bug. In that case how source control (my case is SVN) works. I mean what is the process? Is it like this? 1)one developer creates a project in eclipse 2) does first commit in SVN repo 3)All the other developers creates their own eclipse projects by checkingout from repo. 4) everyone performs changes 5) tests it on single sandbox (will it work?) 6) commits to repo.
    Will this work practically? What do you recommend?

    Thanks a lot!

    • Rick Ross says:

      Hi Jack,

      I do not recommend doing team development in a single sandbox. It is extremely challenging as I suspect you have already figured out.

      When I first started doing team development in Salesforce, everyone was working in the same sandbox and we had constant challenges. One person would fix an issue and publish to Salesforce. Another developer would be working on another issue, fix it and push it to Salesforce and roll back the previously fixed issue(s). It was a nightmare coordinating the efforts of everyone. There would also be times when two people would try to push their changes to Salesforce close to the same time. The second person would have to wait until the first one was complete.

      Developers really need their own space to duplicate the issue, troubleshoot and diagnose the underlying causes and then begin to fix the problem(s). Sharing the same sandbox does not help — it makes it worse.

      Bottom line is don’t do it. Bite the bullet and use multiple developer organizations. Yes it is painful. Yes it can be time consuming. In the long run, it is worth it.

Leave a Reply

Your email address will not be published. Required fields are marked *