Cfrgtkky

Let's say Developer1 is working on Module1, Developer2 is working on Module2 and Module1 depends on Module2. Developer2 has finished working on Module2 today but his changes will break Module1 if he commits his changes to the CI server. But it will take several more days for Developer1 to adapt Module1 for changes in Module2.

What should Developer2 do in terms of Continuous Integration?

1. Commit his daily work and break the build?


2. Wait for Developer1 to finish working on Module1 and then commit together? (Would this be against CI?)


3. Commit to a feature branch (which is OK if it fails to build) instead of the Master branch and when Developer1 finishes his work on the feature branch, merge it into the Master branch. (Would this be against CI?)


4. Write another class instead of modifying the existing one. And when Developer1 finishes his work, he will commit with the switch to your new class. (Kind of like the Open/Closed principle of SOLID I guess)


5. Or some other option?

This a well known problem in many abstractions of development. In a microservice and libraries development environment is common to always provide backward compatibility to some extent. It gives time to other services which depends on it to update until the old functionalities are removed. If this in not an option as it has many drawbacks and requires much planing and culture to make it right I would suggest never breaking the master.

So my answer would be 3 - feature branches are a good option in this case as it fits in almost any workflow and it's simple to make it work with any team.

The reason of my choice is:

• Suggestion 1 I would not use as the master is the canonical version of the software, if this version it's broken, the software is broken. Some developments workflows doesn't even allow devs to commit to the master where merge is done only by the CI after passing all tests and code reviews. It has a cost of managing the CI, code reviews and requires a well defined culture in the team.


• Suggestion 2 I assume it means the developer 2 with a 'staging' ready code lying in his computer just waiting for the dependency to be ready. There is room to him do something wrong while working on other task or mess something up. I always try to commit any code that's meaningful or unfinished in the end of the day to avoid any loss. Usually in a feature branch. It saved me a couple times.


• Suggestion 3 Is the right one for me in this list. It saves the developer's 2 work, does not break the master, and is accessible for the team. Regarding breaking the build, there are some CI systems that a flag in the commit could avoid the build if is known it would break.


• Suggestion 4 This is kind of like the backward compatibility case, but it does not sound right assuming this system does not look like a case for this approach like libraries, frameworks or microservices. I also assume this functionality does not have a planned lifetime of deprecation as it looks just having one module depending on it.

I'm not sure if it's applicable to your case, but using git submodules could solve this issue as well where every module would have its own repository. Each dependency would be a link to another module's repository fixed at a certain version. This avoid dependency breaking problems at the cost of setting and updating the version manually. It can be quite laborious as the number of modules and dependencies grows.