> I am also very much pro everything that raises quality like CI, but remember some groups where doing it in the 1970's.
CI is risky, because it is a great micromanagement tool, just like ticket systems for non-bug tickets. I don't think it is strategic to lure traps for our selves.
I believe one should have a setup such that "good" management wont mess our stuff up and not being dependent on having "great" management.
It is like agile which only works with great programmers and managers but messes up for most of us. But CI is not nearly as bad or dangerous and have benefits if kept simple.
Let me describe to you a system I've seen myself. I think it was created around 1985, in Cobol, by 1 company, for only that company. Afaik, it succesfully runs today.
At the start, there are screens for what we today call issues: 80x25 terminals that input, edit, prioritize and assign changes. Nightly batches provide management views of what is being done where.
Other screens let you check in and out code files, tracking history, linking to issues and people, and managing which versions are on local dev preprod and prod. Nightly batches run the compiler for changes.
Promotion to preprod requires quality checks, where e.g. no new deprecated calls are allowed. Promotion to prod requires a manager sign off, where the input from the test team is validated.
I have not seen this level of integration until github matured. In some ways, github is superior, in other ways the deep integration with their procedures and tech choices is still superior.
That's more than 3 decades, maybe even 4, that this system paid off. It survived the departure and replacement of a whole generation. It survived all attempts to managerial reorgs, and thank god for that. It came from a time that computers where so expensive that having the manpower and long term vision for this was a good choice, even for only 1 company. Unfortunately, it also makes new people relearn everything they know about version management.
Ye. CI systems can be beutiful. And in some companies you want some sort of formal sign off process. I am not dogmatically against CI.
> It survived all attempts to managerial reorgs, and thank god for that
The problem comes when it is cargo culted and forced I guess.
The temptation for some manager to rewrite the system you describe in Groovy and use Jenkins or integrate it into Jira! Imagine the possibilities of unnecessary work and complexity. A big opportunity cost.
CI is risky, because it is a great micromanagement tool, just like ticket systems for non-bug tickets. I don't think it is strategic to lure traps for our selves.
I believe one should have a setup such that "good" management wont mess our stuff up and not being dependent on having "great" management.
It is like agile which only works with great programmers and managers but messes up for most of us. But CI is not nearly as bad or dangerous and have benefits if kept simple.