How to manage multiple products that share code [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

The company I just joined has a system of products that share a large percentage of their code base (via shared links in Visual SourceSafe). There are about 25 product types in this system as well as a PC interface.

The products network together using proprietary protocols that are largely undocumented. Historically, the method for maintaining this mess is to require that all firmware and software is released as a package. This, of course, causes significant delays in release schedules due to the required regression testing.

Has anyone else had a successful method of dealing with this type of issue? We're really getting beat up over it by management (I honestly can't fault them for feeli开发者_运维问答ng this way).

My first thoughts are to try to separate the device releases from each other somehow. Maybe pull shared functionality into libraries which are versioned. Then only update devices that use the libraries that have changed. I see issues with version mismatches from this however.

This is an organizational question. I understand how to keep the house of cards going via testing and processes, but I believe that better organization of the code base could have many good results.

I appreciate the advice.

---

significant delays in release schedules due to the required regression testing.

That's why folks do a "daily build".

Daily builds typically include a set of tests, sometimes called a smoke test ( as in where there is smoke there is fire). These tests are included to assist in determining what may have been broken by the changes included in the latest build. The critical piece of this process is to include new and revised tests as the project progresses.

When the organization -- as a whole -- has to keep the daily build working, then people change their responsibilities, points of view, biases, complaints and actions to keep the daily build running.

Daily stand-up meetings become focused on things that might break the build.

Individual developers have to refactor their code more carefully to avoid breaking the build.

Breaking the build becomes an immediate, instantaneous indicator of something being out of sync. Immediate. No delay. If I break the build today, everyone will know it tomorrow morning. No days were wasted assuming (or hoping) that things still worked. We can immediately roll changes back, or apply changes to keep going forward.