Introduction

Recently, a colleague expressed concern about losing his Jira history upon completing a project, along with all the crucial (functional-safety related) documentation accumulated within it. While exporting each issue to a PDF with attachments may meet compliance requirements, it presents a nightmarish user experience and won’t easily adapt to future customer needs.

During the same period, I stumbled upon git-appraise, sparking a compelling question: Can we replace web-based tools with solutions that store their information, history, and artifacts directly in the repository? This shift would necessitate replacing several critical tools for our use cases:

• Jira: For issue tracking and general project management
• Confluence: As our wiki and documentation platform
• Bamboo: As our CI/CD server
• Artifactory: For storing (Docker) images and other CI/CD artifacts
• Gerrit: For code reviews

It’s important to emphasize that the replacement itself isn’t the core focus here – I recognize the challenge of persuading our customers to embrace command-line interfaces over familiar web UIs. The primary objective lies in centralizing all relevant data alongside the code.

HN link-back.

Jira

Use Cases

I figure Jira is at its core an issue tracker with a set of boards (kanban, backlog, …). The issue can have various status flows attached to them.

Here’s an incomplete list of responsabilities/use-cases propped upon Jira by ingenious PMO that need to be addressed.

• (Kanban) Board / Backlog
• Release Planning
• Earned Value / Spent Effort tracking and planning
• Release Notes
• Requirements/Bugs discussions
  • Attachments. It seems to be a relevant use-case to store attachments with issues.

⚠ Question for the readers: what other use-cases have been implemented with it?

Issue/Bug Tracking

For the basic use-case of tracking Issues and Bugs is covered by either of the following tools. Their respective advantages and downsides are addressed.

git issue

There’s git-issue with an introductory video at FOSDEM’20. It allows to do issue tracking in a git repository.

As a UI it supports syncing to Gitlab and GitHub. There their web interface can be used instead.

git bug

The tool git-bug seems to support the same basic features. The biggest drawback seem to be the lack of attachments to issues. On the plus side there are multiple UI front ends, e.g., terminal, web, &c.

There’s even a board under development.

Release Planning

In Jira one can define the release for which the issue will be fixed. Then all issues that are part of the release show up in the release page of that specific release. With this mechanism one can check if all issues that are planned for a release are done.

Release Notes

Storing release information in the respective issues sounds compelling. It’s not a dedicated tool for the task. The release notes need to be stiched together manually.

As an example, have a look at scriv.

Earned Value / Effort Spent

This is supported by git-issue. However it’s not supported by git-bug.

If the information needs to be duplicated in your time-tracking software, I suggest you track the information there or your project design Excel file. There’s also Projects for the more serious project managers.

Boards

Boards are used to organise issues, bugs, and workflows. Boards only make sense if there’s a proper UI. Hence the only the state needs to be synced.

Support for boards is currently under development in git-bug. Whether this information can be synced is rather unclear. However upon completion of a (sub-)project this information is rather moot.

Requirements

Missing from the above list is a suitable tool to track requirements. I’ve heard people do this in Jira. This brings us back to the above problem and probably shouldn’t be done anyways. Including requirements we should have a complete UNIX philosophy inspired ALM “tool”.

See the following free and open options:

• sphinx-needs
• rmtoo
• doorstop.
• there are others; give it a go in your favourite search engine.

Confluence

It’s about the only wiki out there with a collaborative real-time WYSIWYG editor. The only alternative out there is probably Office365 and Notion. VCS tracked markdown wikis are plentiful, e.g., GitHub uses that for their Wikis.

Locally editing and live-preview is probably a solved problem, e.g., [Gollum] (https://github.com/gollum/gollum). Merely editing markdown see, e.g., (https://typora.io/).

⚠ Linking to issues from the wiki has been used successfully. This can be emulated by creating links to the git-bug ID. This is however not very transferrable to any web UI.

Bamboo

Alternatives to centrally hosted CI/CD tooling should be available at every turn. Jenkins certainly provides everything, the hosting requires some effort though to keep up-to-date.

We assume our builds and tests are going to be reproducible. Then we should be able to run the tests, builds, &c. locally without a centralized infrastructure.

Act allows us to run our CI/CD pipeline locally. The syntax promises to be GitHub Actions compatible.

Artifactory

It is questionable whether this tool can be replaced. We need some form of repository for the OS abstraction. Be that docker, podman, or some other images. These images can’t be reasonably stored in a git repository.

If there are no Docker artifacts being generated, the artifacts can be pushed to the repository using git-lfs. A method to avoid build-loops must be devised if a CI is used.

Gerrit

With git-appraise we can do code reviews in the console. The results are also stored under revision control.

There’s even a read-only UI.

Safety

An important aspect that hasn’t been discussed is access management. Everyone with access to the repository can see all data therein. This might be problem, e.g., if your developers aren’t supposed to have insight into all wiki pages.

This can realisitcally only be solved by using submodules that separate those concerns.

Conclusion

It should be possible to do the full workflow on the console.

However, we can leverage the existing web UI for convenience. We need to be aware of the synchronization tools’ limitations. It probably pays dividends to have plan for all documentation from the beginning. Putting everything into Jira doesn’t sound a like good plan.

There might even be some financial gains to be had by only paying for tools while actually using them.

Missing Key Features

• Putting attachements on issues in Jira will not transfer at the moment.
• Confluence probably doesn’t export gracefully either.