Thoughts on technology and innovation
Ted Husted, Release Engineer
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.
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).
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.
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).
Force.com Packaging in a Nutshell:
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
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 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.
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."