Proposal to make enterprise use the latest core code at all times #62
Conversation
ozamosi
force-pushed
the
enterprise-on-core-main
branch
4 times, most recently
from
0c91120 to
e5cfcfe
Compare
ozamosi
force-pushed
the
enterprise-on-core-main
branch
from
e5cfcfe to
8ad0cff
Compare
|
how feasible would it be to converge the two repos? what would we need to do within the product to serve an OSS and enterprise solution from the same codebase? |
|
It depends. If we want both to be in a public repo, we need to re-do all pipeliines, actions, testing etc, so everything'd grind to a halt a little while we do that. But once we've done that, it'd work. If we want enterprise to be closed but OSS to be public however, then we need to figure out a strategy on how to move code from the closed repo to the public one. In my opinion, this would require the same work as above, and then more work after that, and when we're done it would cause much of the same pain we have, but in reverse (instead of "core code not being available in enterprise" it'd be "enterprise code not being available in core") - and it'd make e.g. signed commit requirements/SBOM stuff more or less impossible because the commits don't have the same history. |
|
this makes sense to me and assuming is something we can implement in minutes, i'd say we should go for it, i'm trying to wrap around the docs side https://www.notion.so/weaveworks/Releasing-WGE-OSS-a9dd20aec5184b83b016e966ba656e9c and this ties in quite nicely, i just annotated something on the board which already existed |
There was a problem hiding this comment.
Yes, I'd love to give this a go. Perhaps with the "update existing PR" as an escape hatch.
For the release component we might need to overhaul the WGE release process to look like the WG one (which I'm very happy to migrate to too).
Did you have a particular action / solution in mind?
| participant Enya | ||
| Oscar->>OSS: Kick off release process | ||
| OSS->>OSS: Opens PR with updated versions | ||
| OSS->>Enterprise: Make release test PR to update versions |
There was a problem hiding this comment.
Not sure if we'd need this one as we'd hopefully already be up to date?
There was a problem hiding this comment.
🤔 Yes. Probably?
My thinking was, OSS creates a branch release/v0.10.0 to start making a release. As Enterprise's main branch tracks OSS main, we'd need to freeze Enterprise at the same version as OSS is releasing, so create a release/v0.10.0 in enterprise that points to the exact versions in release/v0.10.0 from OSS. Do QA, fix any last problems, release, merge. Then that PR can live on for a couple of days if necessary, while development can continue in main.
But you seem to be thinking of it the other way round (release from main, stack changes in PRs), which I don't have a problem with either.
There was a problem hiding this comment.
But you seem to be thinking of it the other way round
Yeah, that is just habit / vibe.
Feels like people might forget to merge to release branch and so we'll need to cherry pick / manage a bit more. vs. devs having to base off track-latest-oss (if we block it from being merged to main for a day or two) as they want new things otherwise the code won't compile.
| this won't prevent Enterprise from releasing a customer-specific | ||
| release - just that the cost of doing that would be slightly | ||
| higher in that it needs to verify both OSS and Enterprise | ||
| functionality. |
There was a problem hiding this comment.
Yes, a potential interim solution might be to update an existing PR in this case:
Scenario:
- WGE is ready to release in 3 days or so for a customer.
- WG does a release v0.10.0 as they have a good cadence.
- PR created and merged in WGE to update to this use this v0.10.0
- WG feature work immediately continues and WebGL powered graph lands in main as
cafe1234 - WGE PR 1234 is created to update to weave-gitops to
cafe1234 - WGE PR 1234 is not merged yet as not ready to release, ETA 2 days.
- WGE PR 1235 is created and worked on which updates to WebGL graphs and was based off of PR 1234
- WG bug fix for WebGL powered graphs lands in main as
beaf5467 - WGE PR 1234 is updated to update to weave-gitops to
beaf5467 - WGE does a release of 0.10.0
- WGE waits 12 hours to see if anything breaks
- WGE merges PR 1234, PR 1235
The PR 1234 would basically become a next-weave-gitops branch really wouldn't it.. now we have multiple branches..
There was a problem hiding this comment.
Yes, if there's a "recent-ish" WG release, it's all good. I was thinking specifically of if WG's cadence is out of step with WGE, so if WG can't release fast enough for $quality_reasons and WGE can't wait for $customer_reasons, then WGE is a bit stuck. But perhaps that's mainly a problem if there's missing communication and inconsistent quality thresholds.
There was a problem hiding this comment.
Yes, there is a need for more co-ord in the WGE teams too, if we have a predictable 2 week cadence too each team can plan their manual release testing etc a bit better.
So if we align w/ WG's cycle that would work well..
I've had luck with If we set a fixed branch name (the "default strategy"), then it should just create 1 PR, update it every time OSS merges, and when that PR is merged it'd just create a new one. We just need to pick a bot with push permission to enterprise and put a PAT from it as a secret into OSS, that's the tracking main bit done. For releases, I think with your escape hatch and release from main approach, we can just use a different branch name - say the first action always pushed to |
|
|
||
| ## Decision | ||
|
|
||
| We will accept the fact that the two code bases are so tightly |
There was a problem hiding this comment.
as suggested in slack https://weaveworks.slack.com/archives/C03QNK53W68/p1661252951461039?thread_ts=1660574525.864539&cid=C03QNK53W68
why dont we have it a go using a branch that follows main main-oss
using the same process but adding a step of
- before raising a PR with OSS changes, we need to rebase changes from
maintomain-oss
Some metrics we could gather to determine whether is a good move are
- avg time OSS is available in main-oss
- number of manual interventions during merges required
- number of manual interventions during release required
- releasability of the resulting branch after brought changes (measured by acceptance testing or similar)
|
Hey @ozamosi how are we doing with this? |
|
Great! Example PRs:
Managed by workflow here: Not sure what next steps are here. Its working very well from my POV. |
What do you think @ozamosi My 2cts as next steps would be to observe it for a bit more - to complete a couple of cycles (for example?)
I guess that after, it would be just a matter of summarising and sharing the benefits and limitations? |
Hopefully a quick way to make development between OSS and enterprise faster, without requiring big changes to our other processes.