Comments by "Brent Jacobs" (@br3nto) on "Leading Teams For Silicon Valley Tech Giants | Randy Shoup In The Engineering Room Ep. 7" video.

Is it a good idea to merge many smaller repos into one big repo? What considerations need to be made when doing this? I came out of this talk wondering if my team of 4 should merge our 20 odd interrelated code repos into a single monolith repo. There’s so much code/design patterns we wish we could extract into libraries and share with the other projects, but the amount of time has proven to be just too prohibitive. A common problem is that when developing or changing features, we need to update the dependent libraries/services first and release before working on the actual feature that will benefit users. This is time consuming and error prone. We need to be 100% accurate with our change to the dependent libraries/services otherwise we will need to perform multiple releases. With a monolithic repo I can see how it would reduce the barrier and time costs as we could develop all the services and libraries in step and release all at the the same time. But I’m hesitant to take this step as I’m not sure if there are any negative or unintended side effects.
2
@ContinuousDelivery thanks Dave for your reply. Smaller steps seems like a good idea. Yes I’ve watched and now rewatched that linked video. It has useful discussion points. I think partially the anxiety is about unlearning “good” practices and getting comfortable with these proven better practices you are teaching us. I’ll report back how we went once we’ve had some time to trial it and build up our experience. Thanks again.
1