Blackthorn SDLC - Getting there from here

To create and maintain our products, Blackthorn follows an industry-standard software development lifecycle process rooted in Agile and Scrum practices.

This page steps through our

• Major Release Roadmap
• Two-week Development Sprints
• Monthly Release Candidates
• Monthly Milestone Releases
• Hotfix Releases
• Repeatable Process

Taken together, these steps create a complete development lifecycle.

Major Release Roadmap

We use our Major Release Roadmap to guide our high-level product direction and keep us pointed to true north.

Our Chief Product Officer maintains the roadmap based on input and feedback from internal and external stakeholders.

The roadmap indicates major items. Our releases include many other items along with the roadmap items, such as resolving defects and improving our technical infrastructure.

Are you a Blackthorn customer with an item of your own? – Submit your Idea through our Community Portal!

Two-week Development Sprints

The roadmap is implemented in a series of two-week work increments or development sprints.

• We manage the sprints using standard Scrum events, such as backlog refinement (with planning poker), daily standups, and sprint retrospectives.
• At a lower level, we use an issue tracker (Jira) to coordinate and document the individual changes we make to the product. An output of sprint planning is a Jira fixVersion for each product that we are releasing, and a set of Jira issues designed to implement the changes needed over the next two-weeks.
• During the sprint, each issue is developed on its own source control branch. We use automations (continuous integration) to create development environments. Automations also ensure that developer unit tests are passing when the work is commited and shared with other developers. For our Events product, we continually run about 1500 developer tests, and we run similar sets for each of the products.
• Before commiting work, the changes are subjected to code review by two other developers, testing by an independent team of QA engineers, and final review by the product owner. To streamline the review process, Developers provide “How to Test“ instructions for each change, with credentials to a test environment where the change is deployed.

Along the way, we create parallel tasks to cover new features in our documentation and other customer-facing resources available through the Blackthorn Community site.

• https://community.blackthorn.io/s/

At the end of each sprint, developers demonstrate the key changes we made in a meeting with other stakeholders.

Monthly Release Candidates

Every four to six weeks, we create monthly release candidates from the completed work increment.

Release candidates are created through a collaboration between three roles – QA Lead, Scrum Master, and Build Engineering Coordinator.

• QA Leads create pull requests in our source control repositories with the new changes that we are preparing to release.
• Our Scrum Master approves the pull request (or calls out items that do not match the release created in our issue tracker).
• When approved, our Build Engineering Coordinator merges the pull request into a release branch, and launches the automation that creates the release deliverable. All releases are created using a set of well-defined automation scripts, to assure consistency.
• Along with the release artifact, we also create a GitHub Release entry for each candidate, which includes a change log and repository tag for future reference.

The release artifacts are passed to QA to validate that the candidates are working as expected in our testing environments.?

• We use a combination of automated regression tests and hands-on exploratory testing to confirm that each release is ready for prime-time.
• For our major products, we have thousands of Selenium-based tests that we run against each release, which can take up to 48 hours to complete.
• And, of course, the test suites are continually extended to cover new features. If a release candidate fails exploratory or regression testing, we resolve the issue and create a another candidate for review.

Final approval of the candidates takes place at a Go/NoGo meeting that includes leads from Product, Engineering, Quality Assurance, and Customer Support.

• To support the Go/NoGo decision, we update a tracking page for each release with all the relevant details for each product that we are releasing that month.

If we do not have an approved set of release candidates, then the production deployments may be postponed.

Monthly Milestone Releases

If all goes as planned, we deploy the monthly milestone release on the second Tuesday, starting at 9am ET.

• Changes to our webapp products are deployed by our Infrastructure team and take immediate effect.
• New Salesforce versions are made available through our Candy Shop (MetaDeploy) site (https://candyshop.blackthorn.io/ ) that helps customers deploy upgrades to individual orgs.
• Updates to the documentation site (https://docs.blackthorn.io/docs) are rolled out at the same time, so that customers can take full advantage of the latest changes.

Our motto is to deliver everything that's done, but not before it's ready.

Hotfix Releases

If a problem with significant impact is found with a release after we go to production, we move quickly to create and deploy a hotfix version.

• Hotfixes to our webapp products are deployed directly and take immediate affect.
• Patches to our Salesforce products are either made available directly to affected customers or the Candy Shop is updated with the new version.
• For a critical issue, we could rollback a Webapp version or deprecate a Salesforce version posted in the Candy Shop (to prevent additional installs).

Customers may also subscribe to system update notifications and other alerts.

Repeatable Process

The process repeats each month, following the same successful pattern, while we continually improve both our product and processes wherever we can.

Are you using a similar development cycle? is there a tactic that we missed that you consider invaluable? Or something that we do that you consider worthless? What would you do instead?