Welcome back to our blog series discussing Crunchy Postgres via Automation (CPA) and the team behind it. This week, we’re going to talk about the tooling used by the team and discuss some of the agile-lite processes we’ve adopted.
Like a lot of other teams, our code is hosted on GitHub under the company’s organization. We currently make use of three different repositories: our main repository hold the actual Ansible collection, while our Bill of Materials (BoM) is hosted in a second, and finally our documentation’s Hugo theme is in a third repository since it’s the official corporate theme shared among many teams.
Obviously, we use Git for our source code. Our main source repository has the BoM and Hugo theme as submodules which allows us to tie version branches together across the different repositories. A majority of the team uses worktrees to manage their development. If you’re not familiar with them, Graphite has a nice write-up on worktrees. IMNSHO, worktrees are the best way to multi-task within a given repository. I even wrote a tool to automate my worktree workflow that others on the team have started using. Finally, the team uses SSH keys for commit signing.
To enforce good Git behavior, we make heavy use of pre-commit in our repositories. We use it to enforce conventional commits, perform linting and enforce several ‘repo standards’.
The entire team uses Vagrant to manage our virtual machines for testing using a custom Vagrantfile managed by yours truly. At the moment, ¾ the team uses VirtualBox virtual machines with one holdout using libvirt (though they plan to convert to VirtualBox soon for consistency and ease of troubleshooting). Our Vagrant boxes are actually built by me using Packer and the templates maintained by the Chef team (the irony is not lost on me).
As mentioned above, we currently use Hugo to generate our product documentation for our customer portal though we’ll be moving to something else before the new year.
One of the first things I implemented after taking over as Lead Architect is using antsibull-changelog to auto-generate our Changelog at release time. Using this tool pairs nicely with the conventional commits mentioned above and makes it so much easier to ensure nothing gets forgotten. We even have a pre-commit check that ensures you’ve added a Changelog fragment.
Crunchy brought Notion into the mix a while back, and while I don’t exactly love it we do use it fairly regularly. We house our team contract, our decision records, and our sprint retrospectives here. We use Notion to record various processes (like our release process), our patch policy, and miscellaneous other documents as well.
We use Geekbot to handle our daily standup, our sprint retrospectives, and to ask the team if they have anything to demo. I absolutely love Geekbot and the team behind it and even managed to get the CPK team to use it. Asynchronous, Slack-based meetings that are coordinated, rolled up, and reported on by a bot just make sense IMHO.
After running into patchback-bot while contributing to the Ansible community.postgresql collection, I quickly adopted it in our main repo. We use this bot to make the sustaining team’s job easier. Our bugfix workflow is such that all fixes land in development first (assuming, of course, that said bug exists there). Once the PR is reviewed and approved, we let this bot attempt to port the fix to our older release lines. It works probably 80% of the time, and when it doesn’t it updates the PR in question with directions on how to handle the port manually. While it’s not perfect, the time that it does save quickly adds up.
While most of the team does not, I make heavy use of Reclaim. I have it fully integrated with my Google Calendar and our issue tracker and it manages my workload as well as my 1:1 mtgs, sprint meetings, blocking time for code review, and several other ‘habits’ (in their terminology). I love this tool so much I pay for it out of my own pocket. I absolutely struggled to stay on top of all my tasks and meetings before, trying to keep my focus on high priority tasks, trying to make sure that tasks I’d ‘completed’ (put up a PR) continued to get attention until they were merged, ensuring I was available to the team for mentorship and co-debugging among any ad hoc items that sprung up killed my productivity and basically ensured that something got lost in the shuffle. With Reclaim, I simply let it schedule my meeting and tasks, and if I need to bump something it’s a simple click and Reclaim will reschedule it. Nothing gets missed, and everything gets its share of attention. I truly don’t think I can go back to working without Reclaim at this point.
You might expect us to use GitHub issues, but Crunchy brought Linear in-house for all teams to use, and I jumped on it. I love the integration with Reclaim and Slack and GitHub. Configuring workflows that auto-update Linear issue’s status when someone puts up a non-draft PR on GitHub and again when said PR is merged; being able to link Slack threads to Linear issues and have a conversation between other developers, the Build team, and our internal customers that stays in sync between Slack and Linear; and having Linear issue’s status auto-update based on Reclaim’s knowledge of what I’m working (and having ’time spent’ auto-recorded in Linear by Reclaim) are just some of the many reasons I love Linear. I absolutely love that we can block our development issues against Build issues, while our Solutions Architect team blocks their delivery issues against ours making the interdependence obvious and auto-notifying everyone as issues resolve. I am so much happier with Linear than I was with GitHub issues.
So there you have it, all the ‘major’ tooling we use currently. And several references to our agile-ish approach to software development: standups, sprints, kickoffs, and retrospectives. I’m not a huge fan of Agile (big ‘A’) or Scrum, but after reading The Phoenix Project (and buying a copy for everyone on the team), I do think there’s merit in being agile (little ‘A’). I’m sure things will change over time, but for now we’ve ‘borrowed’ and adapted a few practices and the team seems to run rather well. For those that care about these things, we’ve adopted a two-week sprint duration, we plan for six sprints per release, and we use a Fibonacci point system that allows 0 points (which we reserve for epics).
I think that about covers things for this topic. Next time, we’ll discuss the brand new CPA 2.2.0 release!
:wq