Unitix Flow is the release management app SolaceIn publishes for Jira alongside Time And History, and it exists because of one hour that kept repeating. Cutting a release across five repositories by hand is not hard work; it is fiddly work, done under time pressure, by whoever remembers which service goes first. The short answer is that the staging branch is created and the task branches merged across the connected repositories from the release itself, in one action rather than an hour of manual merging, and the assembly is kept afterwards. This is what that hour actually costs, what the four release stages replace it with, where a shell script is still the better answer, and what it takes to connect any of it to your Jira.
Releases are easy until there are five repositories
A release in a single repository is a tag. A release across an API, a web client, an auth service and a couple of shared libraries is an hour of careful work: find the branches that belong to this version, merge them into a staging branch in each repo in the right order, discover that two of them conflict, redo one, kick the pipelines, and write down what you did in case anyone asks later.
That hour is not difficult, which is exactly why it never gets fixed — nobody escalates a task they can do. It is also where the mistakes live: the merge in the wrong order, the pipeline nobody kicked, the branch that went in and should not have. Those get found by QA on Thursday, not by you on Tuesday. And nothing about the sequence is written down anywhere a colleague could pick up.
Unitix Flow is built around the idea that this is a job for the tooling, not for that person's memory.
The release stage that costs you the afternoon
A release moves through four stages here — Draft, In Progress, QA, Released — rather than sitting as a date in a calendar, and only one of those stages is the hour you actually lose. It is the second, and it is the one worth automating first.
- Draft — plan the scope and import tasks from Jira or GitLab.
- In Progress — task branches get linked, and the staging branch is assembled across the repositories.
- QA — the test flows run and the results are shared while the release is still open.
- Released — the assembly merges to main and the version is tagged.
Transitions can be automated, so the board describes what is true rather than what somebody remembered to update afterwards.
How to cut a release branch across multiple repositories
Instead of merging by hand in the order only one person remembers, you ask for the staging branch from the release and it is built across every connected repository at once. Those are GitLab repositories: the branch lifecycle — create, merge, delete — lives on the GitLab side, and the Jira side is where the scope comes from.
What a four-repo assembly prints while it runs:
✓ Create staging/v2.4.0 from main
✓ Merge feat/PROJ-142 — payments-api
✓ Merge feat/PROJ-143 — web-client
⟳ Merge feat/SEC-89 — auth-service · merging…
○ Trigger CI/CD pipeline
(Keys invented; the shape is not.)
An hour is what we hear from teams cutting a four- or five-repo release; measure your own once, honestly, before deciding it is worth automating. The claim worth making is not that the assembly beats that hour. It is that the second attempt costs the same as the first, which the hour never does. Three things follow, and each changes a habit rather than a step.
- Re-cutting costs what the first cut cost. A release that has to be re-cut because one task slipped is another run, not another careful hour, so dropping a late task stops being a decision people avoid making.
- The assembly is the record. Each one is kept, so which branches went into v2.4.0 has an answer months later — the detail that is never in the ticket when you actually need it. How many assemblies are kept depends on the plan, which is the thing to check before anyone relies on it as an audit trail.
- The ordering stops being someone's memory. The assembly is repeatable and it is recorded, so what a new joiner has to be told is run the assembly, not ask the person who knows — and the person who knows can take leave in release week.
If you want to see that on your own repository, the free plan covers one repository and one integration, which is enough to watch an assembly run end to end: Unitix Flow for Jira on the Atlassian Marketplace.
Where a script is still the right answer
Jira tracks a release as a version inside one project, and its release view lists the issues carrying that fix version. It does not create branches, it does not merge them, and it does not reach across repositories — so the job has always fallen to a person or to a script. Three shapes of team should keep the script, because a post you have to caveat in the meeting is worse than one you understood beforehand.
- One repository. A tag and a pipeline already do this, and nothing here improves on them.
- Two repositories that always merge in the same order. Fifteen lines of shell is cheaper than an account — until the order changes, or the person who wrote it leaves.
- A release you cut twice a year. The setup will not pay back before you have forgotten how it works.
The assembly earns its keep at three or more repositories, released often enough that re-cutting one is a normal event rather than a crisis.
QA and merge requests in the same flow
Two things sit on top of the assembly, and both are about shortening the gap between merged and trusted.
Merge requests and pipeline state travel with the release rather than being checked one repository at a time, so is this green everywhere has a single place to look instead of four browser tabs and a guess about which one is stale.
QA gets its own engine rather than a spreadsheet: a test case library with steps and expected results, a builder for test flows, and runs tracked pass or fail. The library and the builder are what you would expect. The part that earns its keep is the shareable report — it puts a pass or a fail in front of the person who asked, and that person does not have a Jira licence. The visual flow builder and public share links arrive on the higher plans rather than the entry one, which is worth settling before you plan a QA process around them.
Release management for Jira teams
Unitix Flow does release management inside Jira and does not end at Jira: the release reads its scope from the tracker you already run, so nobody has to retype it, and the repositories it assembles are the GitLab repositories you already push to. Those two — Jira for the tasks, GitLab for the code — are the connections the documentation walks you through, and the product site has the current list of everything else it talks to.
For Jira teams there is a dedicated integration: two-way issue sync, automatic status mapping, sprint and epic linking, and filters in Unitix Flow that pull scope into a release. It is available as an add-on and bundled from the higher plans upward.
Access is worth knowing before the first connection rather than after. Each person can link their own Jira or GitLab account, and then sees only what their own permissions already allow — no shared token for an admin to own, rotate and explain. Teams that would rather not ask everyone to do that give an administrator an allowlist over a shared service account instead. An organisation that configures neither gets the service account's full access, which is the backward-compatible default and not the one to leave in place.
What it costs to try one release
Two facts are checkable today, and they are the two that decide a first release.
The Marketplace lists Unitix Flow for Jira as a free app — the button reads Get it now, not Try it free — and the app needs a Unitix Flow account alongside the Jira install. Budget five minutes for an account, not a purchase order. The free plan covers one repository and one integration: enough to watch an assembly run end to end on the repository you release most often, and not enough for the five-repo case this post is about.
Current plans, limits and prices live at unitixflow.com. This post does not quote them, because a blog post is the wrong place to keep prices true.
Jira release management FAQ
How do I create a release branch across multiple repositories?
Not from Jira, which has no branch of its own to create. In Unitix Flow the release itself is the unit: link the task branches to it, and the staging branch is created from main and the task branches merged across every connected repository in one action instead of one repository at a time. The repositories are GitLab repositories, and the run is kept afterwards.
Can Jira manage a release that spans several Git repositories?
Only as a label. A Jira version lives inside one project, and issues carry it as a fix version; the development panel shows the branches linked to an issue when a Git host is connected. None of that creates a branch, merges one, or knows that four repositories are supposed to ship together — that coordination is the part you are either doing by hand or delegating to a tool.
How do I know which branches went into a release?
The assembly is the answer: each run is kept as a record of what was merged where, which is the detail that is never in the ticket when someone asks in October about a release cut in June. How many runs are retained depends on the plan, so check the retention on the tier you are buying before you treat it as an audit trail.
Do I need GitLab to use this?
For the branch side, yes — the branch lifecycle and the multi-repository assembly run on GitLab repositories today. Jira and GitLab are the two connections the documentation sets up, one for the tasks and one for the code.
Does Unitix Flow replace Jira release versions?
No. The Jira version and its fix versions stay exactly where they are; the release in Unitix Flow is what carries the branches, the pipeline run and the QA results, and the integration syncs the issues between the two so the scope is entered once.
What does Unitix Flow cost?
The Marketplace app is free and requires a Unitix Flow account; the free plan covers one repository and one integration, and the paid tiers are sold off the Marketplace on the product site, linked in the section above. The Jira integration is an add-on, included from the higher plans.
Cut one release this way
Take the release you cut most often, connect the repository it lives in, and run the assembly once. You are looking for one thing: whether re-cutting it costs the same as cutting it. Install Unitix Flow for Jira — free plan, one repository, no purchase order.
Different question, same releases. How long those issues sat in each status before they shipped is Time And History, the Jira Cloud app SolaceIn publishes: five reports built from issue history — Time in Status, Assignee Time, Time to Resolution, Time in Changes and Transition Count — each answering one question, counted in business hours against your work calendar. Install it from the Atlassian Marketplace — free for up to 10 users, so the first team can try it without a purchase order. The instinct is the same one that runs through what a Jira Server board has to get right: put the sequence in the tool, not in someone's head.
Marketplace listing, free-plan limits and the Unitix Flow documentation checked 6 September 2026 — the listing and the product site are the authority.