15th Major Release
Ted Husted – Release Engineer
With Winter ’17 in the rear-view mirror, we’re already well on our way to Spring ’17 — which will be our 15th major release of Nimble AMS. Fifteen seems like a milestone to me.
DevOps on a cloud platform, like Salesforce, brings its own set of challenges, and its own set of safeguards. To keep life simple for our customers, we follow the Salesforce release cadence and change management protocols.
We deliver major versions three times a year, and apply patch versions as needed in between. Before a major release, we update customer sandboxes with a preview version, we run all the local Apex tests for everyone (thanks GearSet!) along with our own set of regression tests, to be sure we stay in the green zone. Production upgrades are rolled out in groups over a two-week period.
Here are a few of the safeguards that are built into the platform to ensure a reliable release process:
- Metadata. Salesforce environments (“orgs”) can be configured through XML documents (“metadata”) which can be transferred back and forth via APIs. We can then version the metadata in source control to track changes we make to managed packages. For some large components, like Custom Objects and Profiles, the metadata deploys are additive: new attributes are merged and other existing attributes are conveniently left alone.
- Permission Sets and Profiles. Salesforce has the amazing ability to make large and small components completely disappear when a user has not been given access. Very helpful when rolling out pilots to selected subscribers.
- API Versioning. With each of the tri annual seasonal release, the API version increases to the next whole number. If need be, we can reference a prior API version on an Apex class, and retain former behavior.
- Namespace. Managed packages are assigned a unique namespaces to avoid conflicts with local customizations.
- Test Coverage. Managed packages are required to have 75% Apex test coverage, which is verified when the package is uploaded.
- Patch Versions. Patch versions cannot include new components or modifications to global interfaces. Patch versions can continue to be issued even though a new major version is available.
- Deployments. Version deployments are atomic. If the release does not deploy correctly, then it is not applied.
- Components. Packaged components cannot be removed from subscriber orgs as part of a version upgrade.
- Scheduled Deployments. Push upgrades can be setup in advance according to a schedule, minimizing human intervention.
- Subscriber Oversight. Package deployments are listed under Setup, and configuration changes are raised in the Setup Audit Log.
- Partner Oversight. The License Management Application tracks all versions installed for all subscribers. When granted access by a subscriber, we can sign into the subcriber org to troubleshoot issues. We are also able to adjust packaged Custom Settings remotely, to activate special options.
Internally, we use several DevOps techniques to be sure we are always release ready and release safe.
- Version Certification. New milestone versions must pass through a gauntlet of certification tests to be made generally available.
- Collaborative Go/NoGo to conclude each sprint and authorize the milestone.
- Automatic suite of external API regression tests.
- Realistic mock customer upgrade.
- Exploratory milestone testing of new features.
- Pilot customer sandboxes, populated with sample data.
- Current GA and Preview versions are available as trials to internal staff and implementation partners.
- Pilot Features. New features are introduced as pilots to selected subscribers to obtain early feedback.
- Change Log. A detailed log is kept for each version, itemizing each change to the product.
- Group Scheduling. New for Spring ’17, releases will be scripted push upgrades so that groups can be scheduled in one click.
For more about how the platform works, see Understanding the Salesforce Architecture: How We Do the Magic We Do (YouTube).
Over the next year or so, the Salesforce DX changes are going to make my life easier, fun even, and I take much comfort in knowing that the platform is watching my back.
Do you miss the old days, when big-bang releases came out every three years? Or do you prefer today’s release-often approach?
Ted Husted is a Kaizen Squad developer on the Nimble AMS product crew. “We make the good changes that create a great product.” For more, follow @tedhusted on Twitter.
