Git and Managed PackagesSeptember 7th, 2011 | Posted by 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
Model 1 Cons
Model 2 Pros
Model 2 Cons
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.