Clojurians Log v2
polylith 2026-10-02
I'm really loving working in a Polylith repository, but we've had some internal discussion about our deployment strategy with our Polylith repository and I was wondering if others might be willing to share their opinion / process.
Our Polylith repository exists of several Apps (projects) which are completely standalone. We've merged them into a single Polylith repository as there are a whole bunch of shared components we kept recreating for each of those apps (and are actively growing because the use of the monorepo). Most business logic lives in their respective project's base.
At every merge to develop the stable-develop tag is moved to the latest commit. At every merge to main, a new vXXX tag is created. For both merges all changed projects are merged to staging and production respectively.
But now two developers were working on two different Apps. The first developer updated a shared component and was ready to for their work to be released. The other developer was still working on a feature and their app (project) was not ready to be released yet. This time we worked around it by cherry picking commits but we agree that that is not feasible strategy.
So, I'm wondering, is this a process issue on side? Are there any deployment strategies, like manual tagging / manual deployment triggering for specific projects? Or did we possibly go overboard trying to work in a single Polylith repository? We could of course look into using feature flags/gates but we've also noticed that could become tedious quite quickly.
Thanks!
Not an answer to your question, but I'm wondering why the work of developer 2 was merged into stable / staging when he was not ready?
You probably had a good reason for that so it is more to understand what the options are
In the case you have to merge for whatever reason, one strategy is for developer 2 to not change the shared component. Some possibilities: • Create another component, a full copy if you have to, with the same interface, and require that in that particular project over the shared component. You can redo and cleanup when everything is ready. • Maybe it is a small change/addition somewhere else and you don't have to change the shared component
FYI, i'm just thinking out loud and I haven't run into this problem with Polylith, but similar problems before Polylith. I'm looking forward to hear other peoples experiences
This feels like a process issue with how you manage git and longer lived branches, and would happen without Polylith. 1. Developers should be communicating better about changing any shared logic in a repo 2. Developers working on longer lived branches should probably be merging the main branch into their work regularly, to keep up with what is being released.
And, I guess, 3. If you change shared logic, it's your job to change it across the whole repo, not just inside "your" app
I appreciate the thinking out loud, that is what I was looking for. I agree that it is likely a process issue. Coming from multiple a repository per app we where able to develop on feature until we felt it we believed it was completely ready (big feature existing of multiple subtasks), so the develop branch is long lived before it merges to main. I now also realise that this problem will happen (in our current workflow) regardless of a shared component or not. If work in develop for 2 different apps exist where one is ready and one is not we run into the same issue. I guess the first thing we'll have to look into is smaller deployable states our apps should be in, even if a bigger feature requires more work.
develop on feature until we felt it we believed it was completely readyYou can still do this and at at the same time be merging regularly. Just don't move things to shared components too early. Many times it is better to have duplicated/similar code than rigid shared code that many things depend on. Of course there is a balance. So like Sean is saying a lot of this is process indeed. I have been on teams where not being DRY was a curse (good old Ruby on Rails times), but many times the shared abstractions are not great.
Also, process wise you must not allow the breaking of the contracts (compoent API) in the shared published components. Changes can only be additive, otherwise you risk breaking other apps without knowing it. In larger organizations shared components may start to live their own life with own release versions which allows depending apps to stick to working versions.