Using a version control system with Force.com

By Nick Simha | Published: June 10, 2009

The Development as a Service (DaaS) suite of features with Force.com allows integration with existing software tools to facilitate easy development and deployment of applications in the cloud.  In this tutorial , I go through the use of Subversion a free, open source version control system to facilitate team development on Force.com.  Since a version control system can keep track of every change you make to files under its control (who, what and when) it is invaluable when you want to go back to a particular state or just try to figure out how the system evolved.  I strongly recommend that you use a version control system as part of your development process – it is fairly quick and easy to set up and well worth the investment in time.  As your team grows, you probably would want one of the developers to have a deeper level of knowledge on the version control system to be able to administer it on a part time basis.

We would love to hear from you on any team development best practices that you would like to share and your experience with the DaaS suite of tools.  As a followup to this article, I am looking into Cruise Control for continuous integration.  Please share any experience you may have with this (or other similar tools) esp. if you are already using it for Force.com development.

tagged Bookmark the permalink. Trackbacks are closed, but you can post a comment.
  • http://www.reside.biz Don

    Nick – We’ve been using Subversion for quite some time, and it’s worked extremely well when we began using it for force.com development a few years ago. IMHO, the critical concept for any Subversion repository is consistency in the structure. We’ve found the structure below very helpful in organizing files for every aspect of a force.com application – hopefully others find it useful. Would be interested in a follow-up on using CruiseControl for force.com development as well!
    codebase
    — branches
    — tags
    — trunk
    —— force.com
    ——— apex
    ———— classes
    ———— components
    ———— pages
    ———— staticresources
    ———— triggers
    ——— branding
    ———— css
    ———— documents
    ———— images
    ———— js
    ——— config
    ——— scontrol

  • Andy

    Nice article, plus tutorial. Our team is new to SFDC. We have an existing, mature process using Cruisecontrol and are only just now getting our version control (CA SCM) process established. I’m interested in this comment about directory structure. From what (little) I’ve seen, it seems to make a lot of sense to mimic the SFDC directory structure for code. E.g., when one checks in a project, it naturally creates a directory such as:
    src
    |– application
    |– classes
    |– pages
    |– (all the other datatypes)
    It seems like it would be awkward to break that natural structure, having somehow to map the sfdc server structure to the version control structure. Could be I’m mistaking your structure — is everything under “apex” the same object types that I layout above?
    Nick – I’ll let you know our updates as we progress. Starting next week should have a lot to share and discuss!
    - Andy

  • Nick Simha

    Don,
    Thank you for sharing the structure that you currently have. Could you please also share how you arrived at this particular structure? Like Andy’s question above, I am curious on the rationale behind this structure.

  • http://www.reside.biz Don

    Great question. We’ve settled (for now) with this structure, as it served as a great hybrid between what Eclipse created by default with the force.com plug-in and with what was logical to keep track of files across a more complex project (e.g. one that included Apex classes and triggers, Visualforce pages, with a Customer Portal that needed to be branded w/ JS and CSS). It also provided us with a structure to be able to properly manage branches and tags as customers released new features.