On 2020-02-10 17:40:47 +0100 (+0100), Simon Richter wrote: [...] > It can absolutely be done, and I'm doing that myself, but I often > find myself fighting implicit assumptions in the framework, and > either I'm doing it entirely wrong or these assumptions apply to > the majority of users. No, I think that's an entirely fair assessment. If you don't build the CI system yourself (and most folks don't), you end up fitting your release models to the tools you have rather than fitting the tools to the release models you want. > The most annoying instance is that there is a notion of a single > "current" state for every project and dependency. I can set up a > copy of my pipeline to implement a "stable" or "production" > variant, but I have yet to see a CI system that is powerful enough > to analyze a stable branch for regressions compared to the > branch-off point without a lot of hand-holding. For each release > branch, I find myself copying the existing pipelines and pointing > the new instances at the new branch. At least the open source CI system we're using (Zuul) considers every branch of every Git repository as a current state, though it's also less concerned with "current" states of repos than it is with speculative future states since it's technically more of a project gating system than traditional CI. Testing every commit in context before it's allowed to merge reduces the risk that you pick a bad branch point. Also having the ability to branch your job configuration along with your source code makes a big difference when it comes to handling behavior needs for stable maintenance, and avoiding development in master from bleeding into those stable jobs. -- Jeremy Stanley
Attachment:
signature.asc
Description: PGP signature