Header

Git and Managed Packages

September 7th, 2011 | Posted by kbromer in Salesforce

This post is a bit more on the technical side.

The Devzone at Dreamforce this year was abuzz with git, the awesome distributed version control system that’s rapidly gaining fans in the developer community. Having a chance to chat with some of the guys from github, as well as hear some amazing talks on the topic, I’ve been inspired to begin the process of moving the Nonprofit Starter Pack code from our older SVN repository. The social pieces, as well as the ease of sharing with the community are just a couple of reasons for the switch.

Regardless, this brought me to a bit of an impasse. I know my preferred force.com development workflow pretty solidly using SVN, but hadn’t played around with git enough to know how I was going to tackle it. After some serious whiteboarding sessions, I narrowed it down to two approaches, and would love any feedback the community has. I’ve diagrammed them out below and provided my initial pros/cons for both options as well.

Its important to note that I’m working in a managed package environment. If you’re not familiar with that setup, you may want to read up on the environment. Kevin Swiggum has an awesome overview of this here. You can also check out the Salesforce Package Guide.

The key thing to understand is that you have a single developer org that produces major releases (2.1). Once a major release is out, you then create a patch org for that specific major release. From that patch org, you can push minor code changes as updates to your major release (2.1.1, 2.1.2, 2.1.3, etc.) Once you have a second major release (2.2), you get a brand new patch org that’s in sync with your developer org. As you’re release patches from your patch org, you’re also continuing development of the next version in your developer org.

Okay, enough overview. Here’s a brief synopsis of both models:

Model 1: Main DE org as master. Patch orgs as branches. Tags for push releases come from patch branches, tags for major releases come from master org.

Model 2: Patch org as master. DE org as branches. Tags for push releases come from main, tags for major releases come from branch (or main post-merge)

The biggest issue in general is that they’re both reliant on project participants understanding what can be pushes and what needs a major release, which is less than ideal. However, I don’t think there’s any way around that issue, and its common to both systems, so we’ll set it aside for now. Other thoughts:

Model 1 Pros

  • Easier to Maintain Internally since Org Switching only happens when a new patch branch is created
  • Master branch is consistently from the same org
  • Uses merge to push patch org changes back into the master branch

    • Model 1 Cons

  • Active patch branch points to different orgs at different times
  • Master branch can become unstable during development
  • Breaks branch=dev and master=stable model

    • Model 2 Pros

  • Master is always stable
  • More “VSC Friendly” since dev occurs in branches
  • More transparent to participants, abstracts the SFDC org from the repo

    • Model 2 Cons

  • More complex to maintain as SFDC org hooked to master is a patch org
  • Rebasing less reliable and consistent for participants (lose commit logs?)
  • Master branch points to different SFDC orgs at different times
  • Major releases will technically happen from branch since that’s the master dev org

    • There’s also a great stackoverflow post on this here. Its not quite equivalent since they’re not working in a managed package environment, but does provide some good background.

    , ,

    You can follow any responses to this entry through the RSS 2.0 Both comments and pings are currently closed.