Vital Beats

Jira's great strength is almost it's great weakness: Customisation of ticket types and workflow.

Hand Jira over to an engineer, and they will quite quickly try to build a workflow for tickets that tries to model every possible state your work might be in, every possible holding point etc. The end result will be a workflow no-one understands well enough to navigate. Hand Jira over to a manager, and they'll throw it back at you, as the mechanism for changing workflows is not drag and drop, and reporting relies on Jira query language, across fields they don't understand are used or not.

Unfortunately both approaches miss the main purpose of work planning and tickets as a process. You are not trying to model software development in full. Software development is messy, and honestly it is too difficult to reason over such detail. Likewise, your software development workflow does not change often. Maybe ... once, twice a year or so?

If you have a sit down, and ask "What is the minimum useful information the team and it's stakeholders need to see?", and model that at as high a level as possible, you will end up with a Jira system that is simple, easy to use, and actually matches your working practices.

The reason I have laid that out, is because it helps explain why Vital Beats went with Jira, and not with GitHub issues, or ClickUp.

GitHub issues provides a fairly repository centric idea about tickets, and their workflows. At Vital Beats, multiple repositories are glued together to contribute to different solutions, and so it is not the case that one repository = one product or team.

ClickUp prescribes a particular workflow. It is a broad and fairly common workflow, and works if you don't have a prior practice in mind ... but it's not Vital Beats workflow. When boiled down, our workflow had both less fields and different workflow states than ClickUp offered, and for stakeholders we wanted to offer a higher abstraction, to answer those broad questions like "How close are we to release?" without getting into putting date deadlines on tickets and getting into hourly estimation.

Jira let us stay in a good level of agile thinking, while providing different views for different audiences. We stripped it down to it's bare minimum, and it works without being "I need to spend time doing backlog monkey work". As our engineering team expands, our workflow too can expand if needed ... or encompass distinct workflows that match team styles, while still offering that higher level view for stakeholders.

Configure once, configure simply, configure infrequently, and you will have the satisfaction with Jira that we at Vital Beats have had!

Within our deployment pipeline, we have a need to deploy to multiple customer environments, and manage secrets specifically in a way that integrates well with AWS, Kubernetes Secrets, Terraform and our pipelines ourselves.

Jenkins offered us the ability to choose one of a number of credentials/secrets management approaches, and models secrets as a more dynamic concept that GitHub Actions provided.

Additionally, we are operating Jenkins within our development Kubernetes cluster as a kind of system-wide orchestrator, allowing us to use Kubernetes pods as build agents, avoiding the ongoing direct costs associated with GitHub Actions minutes / per-user pricing. Obviously as a consequence we take on the indirect costs of maintain Jenkins itself, patching it, upgrading etc. However our experience with managing Jenkins via Kubernetes and declarative Jenkins configuration has led us to believe that this cost is small, particularly as the majority of actual building and testing is handled inside docker containers and Kubernetes, alleviating the need for less supported plugins that may make Jenkins administration more difficult.