NuOps: How the Nimble AMS Sausages are Made

Ted Husted

January 20, 2015

    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.

    While this high-level process description is specific to the Nimble AMS project, other 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 ( 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.

    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.

    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 creates new versions of a package. Packaging in a Nutshell:

    • Every 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.

    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, we’d be happy to share more.

    If you are interested in developing enterprise-grade apps, please also visit the site.

    For more about delivering software with Agile methodologies, see ReadMe First!

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

    More industry insights, delivered to your inbox. Sign up for our blog!

    Recommended for you

    07/17/24 Association Management

    The crucial role of software testing in your AMS implementation

    5 min read
    07/10/24 Association Management

    3 tips to prepare your organization for new technology

    5 min read
    06/12/24 Association Management

    7 benefits of stored payment information

    5 min read

    Blog Subscribe

    This will close in 0 seconds