NuOps: How the Nimble AMS Sausages are Made

Nimble AMS is created using an agile methodology and a sophisticated set of tools. The framework is a seamless continuous integration platform integrating JIRA, BitBucket, TeamCity, and the Salesforce Migration Tool. JIRA - Team activity tracking BitBucket - Source code version control TeamCity - Continuous integration and deployment server ...

Nimble AMS is created using an agile methodology and a sophisticated set of tools. The framework is a seamless continuous integration platform integrating JIRA, BitBucket, TeamCity, and the Salesforce Migration Tool.

While this high-level process description is specific to the Nimble AMS project, other Force.com projects can make use of the same design. For example, the CumulusCI project on GitHub uses a similar process to manage five interrelated Salesforce apps.

The balance of this article steps through building the Nimble AMS package, which is powered by two millions characters of code (78k lines), fifty objects, and a crew of ten developers working in three squads (Roadmap, Readiness, and Kaizen).

Managing Progress

To keep it all in check, our development crew uses a Scrum process (www.scrum.org) where every work item has a corresponding issue in JIRA. The JIRA issue ID is referenced in each commit, providing a surprisingly powerful audit trail.

Each JIRA issue moves across an Agile board with columns for In-Progress, Ready-to-Test, Code-Review-1, and Code-Review-2. We right-size the work for each issue so that it can be ready-to-test after a day or two of development. 

The testing and first code review can be conducted by any developer on the product crew. The second code review is performed by one of our more experienced developers, which we dub Subject Matter Experts (SMEs). All Nimble AMS code is reviewed by a SME before it is accepted into the main line of development (aka “develop”).

Each JIRA issue has its own feature environment -- which includes a feature branch and a feature org. Feature orgs are trials created from a Trialforce Source Org and kept in sync with the feature branch using an IDE or the Migration Tool. 

When a feature branch is merged into develop, TeamCity detects the change and deploys the latest code to the feature source org (courtesy of the Migration Tool), where it can be incorporated into the next Trialforce template.

Feature environments are created for a single use and then discarded. Feature branches are automatically deleted when the branch is merged back into develop, and feature orgs automatically expire in 90 days.

Creating Releases

Nimble AMS schedules three major releases a year that roughly coincide with the Salesforce seasonal releases. Also like Salesforce, a Preview version of Nimble AMS is made available to selected customer sandboxes prior to the product rollout.

The key lifecycle stages of a product version -- develop, preview, and master (GA) -- are represented by three persistent branches in the Nimble AMS repository (ams-app).

  • Develop - create new features and fixes for the next preview version.
  • Preview - deploy, test, and patch the next GA version.
  • Master - patch the current GA version.

A fourth (and final) persistent branch -- packaging -- is used to kick off the Salesforce version upload cycle. The packaging branch reflects how Force.com creates new versions of a package.

Force.com Packaging in a Nutshell:

  • Every Force.com package is assigned a version number by the platform in the format "majorNumber.minorNumber.patchNumber".
    • For example, "1.23.4", is the first major release series, twenty-third minor release, and fourth patch version.
  • Each managed package is associated with a particular Developer Edition org that handles uploads of all new major and minor versions.
  • Patch versions of a managed package are handled by a separate "patch org". Each minor version has its own patch org, with its own username. New components cannot be added to a patch version, but code changes can be made to any component already in the package.
  • The Nimble AMS packaging branch deploys to our main packaging org. The preview and master branches deploy to patch orgs. As new versions are uploaded, new patch orgs are created, and we update the TeamCity builds to use the new patch orgs.

Finishing Up

At the beginning of each sprint, before any new changes are merged, the source org template is refreshed, and a feature environment created for readying the sprint increment.

Our readiness process remedies issues which prevent the “potentially releasable” work increment from going into production. Key gaps include help topics for new features and thorough user acceptance testing.

Inputs to the readiness process include

  • the peer test plan from the prior sprint,
  • the list of development issues completed in the prior sprint, and
  • the work increment presented in the prior Sprint Review.

Outputs are

  • the "Delivered" help topic that recaps development tasks and stories,
  • exploratory validation and verification testing, and
  • help topics for new or amended features.

Additional user acceptance testing takes place during the preview process, when customer sandboxes are upgraded with the latest managed version of Nimble AMS.

Rinse and Repeat

As each sprint ends, and another one begins, we can keep progress moving forward, and all our production orgs up to date, even while new releases roll out the door.

This blog hits the high points, but, of course, the troubles are in the details. If anyone wants to learn more about the nuts-and-bolts of how we do continuous delivery with Force.com, we'd be happy to share more. 

If you are interested in developing enterprise-grade Force.com apps, please also visit the www.dreamops.org site.


Ted Husted is a Kaizen Squad developer on the Nimble AMS product crew. "We make the good changes that create a great product."

Source: www.nimbleams.com