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 software delivery 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
  • Migration Tool – Source code transfer utility

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).

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.

Essentially, the JIRA issue is a proper Scrum task: the smallest coherent unit of work that we can test and review.

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 development environment — which includes a task branch and a task org. Task orgs are trials created from a Trialforce Source Org and kept in sync with the task branch using an IDE or the Migration Tool.

When a task branch is merged back into the mainline, TeamCity detects the change and deploys the latest code to the develop source org (courtesy of the Migration Tool), where it can be incorporated into the next Trialforce template.
​
Task environments are created for a single use and then discarded. Task branches are automatically deleted when the branch is merged back into develop, and our task orgs automatically expire.

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.

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.

While we don’t try to deliver “continuously”, and push work items out one by one, we do deliver “continually”, by delivering strategic patches regularly, and delivering new features several times a year.
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 continual 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.