ShipShip is an automated Kanban board that fetches information from GitHub, Altus, and Jenkins, stitches everything together, and throws out an automated Kanban board that moves with pull requests, builds, and deployments. The only manual step in the process is to manually verify each story in QA.
This started out as a quick tool created as a part of my internship to show deployment status for every commit on our master branch. After the initial version was released, we kept adding more and more helpful features, and now it is a stand-alone service we use every day for stand-ups and deployments.
We strive for continuous delivery, working closely to the GitHub flow. In a nutshell, for each piece of work, we create a pull request. When ready, after review, it is merged back to master. After going through a CI, we check our changes in QA/staging before deploying master to production. We have built ShipShip to work around us.
Examples
At Shutl, we use seven columns to track the progress of anything, as shown in the following figure.
Let’s follow a story.
Notice the conflicts in this pull request.
This is the card that opens when a new pull request is opened, usually in the “in progress” or the “review” columns, indicating whether it is ready or still being worked on. It allows you to see the team, the repo, the author — all the usual suspects, as taken from Git and our deployment tool. It also shows conflicts and whether or not the PR build is broken. The only difference between work in progress and review is if you have tagged it for review on Git.
The grey clock symbolizes that this is merged and not yet deployed.
In QA, the engineer checks it out. Notice this is the first time you’ve interacted with ShipShip directly. You sign off whether the change has the desired effect on QA. Shortly after, a product manager will run an acceptance test to say this is indeed the changes requested.
A reset button is provided for misclicks and misunderstandings. If there’s something to communicate, you can even comment to point things out. To filter out some noise, there are filters for individual users, projects, and teams. Here we are going to filter cards being worked on by the Moshpit team.
Filter in use.
In order to be more visual, there are also "blocker" and "blocked" tags. The banners also auto neutralize when a broken PR is fixed by a later PR.
After making sure your card has no blockers, you can deploy, and the card will move to the correct column. There's also a detailed view of cards for when you want to revisit them.
Detailed view of a card.
This has helped us support each other better as engineers and has been key in helping communication between different teams. It was also a great way for me to learn the whole lifecycle of the development process as an intern.