Git Based SDLC
Git-Based Software Development Life-Cycle

          

        
            


    
    
        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.

    




          

        
      