What goes into a feature branch for CumulusCI

Question

I'm looking to setup continuous integration, but getting stumped with our custom solution. I'm starting to look into CumulusCI managed by Salesforce Foundation. I'm having difficulty finding what "a day in life" is like - i.e. what does it look like to retrieve from the individual org, how does merging with dev work, etc).

My main questions are:

• How do you include configuration changes (from adding a field to creating a flow)? Looking at some commits in the cumulus project; it appears only programmatic code goes into a feature branch and all configuration changes are made on Dev which uses the deployCI target to pull request the change into any active feature branch.

• What is the developer responsible for retrieving from their org (i.e. what does their package.xml look like)? Do they patch their additions and modifications to the package.xml cloned from Dev, do they retrieve a full metadata package, or do they update the package.xml to only include their additions and modifications?

Although the demo has good content, I'd like to see it in action before I setup and config.

I know these are pretty specific questions, but I figured the community could benefit from this knowledge as well.

Answer 1

I can provide a more specific answer from the CumulusCI perspective. First off, the webinar you linked to is quite old. Here's some better reference materials:

Dreamforce 14 Session Videos:

• Automating the Impossible
• Reusable Build Scripts for Managed Package Development

Other Resources

• Nonprofit Starter Pack Contributor Docs

• Diagram from Automating the Impossible Use left/right arrow to navigate through. Install the octicons.ttf font to see the icons instead of squares

As for a working example, we actively use CumulusCI for a number of open source managed package projects so you can easily see it all in action:

• Jenkins
• Cumulus (Nonprofit Starter Pack 3) Github Repository
• mrbelvedere Installer for Nonprofit Starter Pack 3

One important point is that CumulusCI is built pretty exclusively for development of Managed Packages rather than for maintaining single org customizations. That said, probably 80-90% of it would be reusable for a single org scenario. I just haven't actually had the use case to build that yet and thus can't speak to if it's a good fit.

If you're doing Managed Package development, the key thing to keep in mind is that your repository should contain the metadata that's going into your package. The only thing you can put into a Managed Package is metadata. Metadata can be easily worked with as files. So the developer's workflow for package development is retrieving and deploying files to/from a Salesforce org and the version control repository.

Merging

All merging of code is done via Github Pull Requests which are also used to track code review. CumulusCI also includes a script which can automate the push of new commits on the master branch (i.e. after a Pull Request is merged) into all open feature branches so the feature branches track as close to master as possible. This has been really helpful in our productivity as it reduces test/build failures and merge conflicts.

package.xml and retrieve/deploy

As for the package.xml question, developers are deploying and retrieving the entire set of package metadata when they use the build scripts. Retrieves use the packageNames attribute to only retrieve the metadata in the package. This type of retrieve doesn't require a package.xml manifest, just a package name. Deploys use <fullName>Your Package Name Here</fullName> in the package.xml to specify that the deployed metadata should all be automatically added to the package. This makes a round trip container for your metadata to get into and out of the org. If a developer adds new metadata, they can use the ant updatePackageXml target to rebuild the package.xml based on the metadata in the src directory.

Shameless Community Pitch

CumulusCI was built to prevent the reinventing the wheel you alluded to at the start of your question. It's open source and the build scripts are architected in a way to encourage contributions back to the main repo, allow users to easily update the build scripts (git pull), and has built in hooks providing projects the flexibility to override core functionality for project specific needs.

I will confess is that the documentation for it is definitely lacking. It's not necessarily my strong point and I'd love to work with someone in the community who would be interesting in writing documentation to make it easier for others to use CumulusCI.

Answer 2

Disclaimer: I work for Gearset.

I can't speak directly about CumulusCI, but I can talk about some of our experiences over the past 12 months talking to Salesforce developers and admins all over the world about their existing deployment / CI processes.

With respect to your specific questions:

• I think in an ideal world, configuration changes should be handled by the same mechanism as code changes. It's all metadata, at the end of the day. At Gearset, we allow folks to make all those changes using their existing workflows (including e.g. Eclipse, MavensMate, etc. for code changes), with the goal to then make it easy to commit those changes from a dev org to a VCS, e.g. GitHub.

• That's a good question. In my experience, a common solution-agnostic approach (i.e. just assuming Ant, without reference to CumulusCI) is to pull the smallest subset of metadata you can, given the changes you know you've made. Of course, different practises mean that it's not always easy to know what the smallest subset is, so it's not uncommon to see rather broad package.xml files for retrieval. From there, it's possible to build a separate deployment-specific package.xml listing just the elements that have changed. With Gearset we handle this by letting you pick a subset of metadata types for that retrieve operation, and then make it easy to build the deployment package by performing comparisons complete with line-by-line diffs and our own dependency engine.

I can also point you towards a whitepaper that we've put together at Gearset, based on our research. It describes a full CI process for Salesforce, which I hope covers that "day in the life" scenario.

I don't think I've been able to answer your question directly, but hopefully I've provided some useful background and filled in a few gaps, at least!