|
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. |
> 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.