|
|
|
|
|
|
by oaw-bct-ar-bamf
2116 days ago
|
|
|
4. Split up the codebase into modules.
You yourself cannot change these modules. Only the ‚module experts‘ are allowed to change their own modules.
Your final executable will consist of ~200 such modules. If you find bugs / problems you will need to convince the module owners that is in fact a bug in their module. And modules are delivered only every 4/5 months.. |
|
|
It had a repository in subversion but modules were versioned by their owners by making copy of the code in a new folder with version in the name.
Builds were not automated and instead each module owner built it manually in Eclipse and "uploaded" them binaries to svn. Each module had a single owner, nobody else knew anything about the module except for the owner. Builds could not be executed when the owner was not available.
I was required to "prove myself" before I was given read access to module I was supposed to start my work on.
The application had a lot of problems in the form of "there was a bug a month ago and now it reappeared because somebody forgot to include the module in the updated version this deployment".
There was ostensibly a "database layer" but different versions of it were used throughout the application. The versions were really branches of it because they included workarounds for app-specific problems that they did not want to be present on other services for the reason of "stability". This of course made it a nightmare for me when I decided to create a proper Gradle build.
Each jar or class was updated separately. I spent a quarter trying to convince teams with their managers that just versioning everything together and deploying everything everywhere at the same time is going to be a better strategy. They said if updating single jars and classes causes so many problems then updating everything has no chance of working. 2 years after I made the change there was still not a single deployment that would fail.