A few of us on the Tracker team started to explore different development processes with Tracker since we weren’t really satisfied with how our current development and release processes were aligned.
Our process used to look something like this:
At around Step 3, the team wants to deploy a set of bug fixes, but they can’t deploy from master since previous code for the partially completed story has not been accepted. So we wait for the story to get accepted, then wait some more…when another commit sneaks into master and the problem repeats itself.
<img src=”/marketing_assets/blog/2017/PWS1-d0c312b800fb9eb85fbd907b27f4f064746ad7d047b85f866e65a0b362fd90b3.svg” alt=Typical dev process on Pivotal Tracker. width=”480” height=”352” alt=”blog/2017/PWS1.svg”>
So, there are a few issues:
We realized that the Product team really has no control over when to deliver value to the customer because all commits for past and future features were intertwined in master. We explored GitHub Flow and found that pull requests (PR) can be a great lever for the PM/Tester to decide if a feature is ready to go.
Pull requests gate the code before it can be merged into master with a big green Merge button. There are also visual indicators on a PR, identifying that the code passed CI build checks or that there has been a code review.
For us, the Merge button is the lever that says not only do all the engineering checks pass, but so do the requirements from Product. So for every story, we create a PR and let the PM or Tester merge in the code.
The PR is also a good indicator on whether or not you should do acceptance on a story. If a code review has not happened or a build check has not passed, the story might not be in a good state to do acceptance.
But in order for this approach to work for us, the old way of deploying to dedicated test environments like alpha, demo, and staging would have to change as well. Since each story has its own PR, the code is isolated and cannot be tested in one environment.
For a while, we thought, “Wouldn’t it be nice to test each story in an isolated test environment?” With Pivotal Web Services (PWS), it’s extremely easy to push our app to its own environment with its own unique URL.
As a part of our Concourse CI pipeline, we automatically deploy our code to PWS. PWS then spins up the app (and related services like P-MySQL, Redis, etc.). For each story, we now have a stable test environment and a bit of test data to do acceptance and exploratory testing.
With isolated environments, there is no longer any confusion about where a commit is—we now know exactly where a story lives.
So now our process looks like this:
<img src=”/marketing_assets/blog/2017/PWS2-bedcf97b7ba8c001d2f4d627b3904c712ca8a5e4002ae9df0cf87214e39e7529.svg” alt=New dev process on Pivotal Tracker. width=”480” height=”352” alt=”blog/2017/PWS2.svg”>
After trying out this experiment to our process, we’ve noticed a few benefits:
We’re beginning to build out features around pull requests and commit statuses in Pivotal Tracker. If you’d like to help shape these features, please reach out to us via email.