0

In Software Engineering by Pressman:

The steps in continuous integration are:

  1. Check out the mainline system from the version management system into the developer's private workspace.
  2. Build the system and run automated tests to ensure that the built system passes all tests. If not, the build is broken and you should inform whoever checked in the last baseline system. They are responsible for repairing the problem.
  3. Make the changes to the system components.
  4. Build the system in the private workspace and rerun system tests. If the tests fail, continue editing.
  5. Once the system has passed its tests, check it into the build system but do not commit it as a new system baseline.
  6. Build the system on the build server and run the tests. You need to do this in case others have modified components since you checked out the system. If this is the case, check out the components that have failed and edit these so that tests pass on your private workspace.
  7. If the system passes its tests on the build system, then commit the changes you have made as a new baseline in the system mainline.

I was wondering what does this in 6 means:

If this is the case, check out the components that have failed and edit these so that tests pass on your private workspace.

?

What does "these" in "edit these" refer to? The components that was modified by others since I last last check out? Or the components that was changed by me after my last last check out?

If "others have modified components since you checked out the system", what would you do?

Note the book used CVS as version control tool. Will it be different if using Git?

Thanks.

Tim
  • 5,405
  • 7
  • 48
  • 84
  • 3
    So, for some context: since this is a continuous integration scenario, it's assumed that the edited components were already working (all tests were passing) before you checked in your changes, but, since you were developing against an older version of the system, the combined changes (yours and theirs) resulted, once they were brought together, in some kind of an interaction that caused some tests to fail. So you need to try and figure out why, and fix the issue if you can, whatever it might be (or call in someone who can help), before committing again. – Filip Milovanović Jan 27 '23 at 07:11
  • 2
    Yes, this is different to git. This is an old book and CVS is an old system. It may not be worth learning unless you have a use for it. Git doesn't really have a concept of 'checking out' in the same way. CVS had a feature where one developer could checkout a file and stop others editing it https://softwareengineering.stackexchange.com/q/184592/23915 – bdsl Jan 27 '23 at 14:47
  • Git instead allows everyone to edit the same file at the same time if they want to, and lets you deal with merging people's changes together later. You don't have to tell the system in advance which file you plan to work on. – bdsl Jan 27 '23 at 14:48
  • 1
    think its very clear "check out **the components that have failed** and edit these" – Ewan Jan 27 '23 at 16:17
  • Typically we expect that a module has an owner, and that changes happen through frequent sprint planning. If two developers simultaneously work on different features that are hard to merge, that indicates improvements are needed in the sprint planning process, to coordinate efforts. – J_H Jan 27 '23 at 21:59

2 Answers2

5

What does "these" in "edit these" refer to? The components that was modified by others since I last last check out? Or the components that was changed by me after my last last check out?

Honestly it's both. Obviously if you can resolve the conflict by sticking to editing the components you were already making changes to it's better. If you can't you need to dig into why and see if you can figure out why the changes in the other components make what you're trying to do impossible. Those other components were likely changed for a reason so if you 'fix' them you're on the hook for that too. It might be some massive architectural restructuring. It might be a typo. Merge conflicts come in many sizes. Sometimes you just need to talk to whoever broke your stuff.

Keeping problems like this small is why you should commit and merge often.

candied_orange
  • 102,279
  • 24
  • 197
  • 315
  • In this case... commit and merge often I guess – Laiv Jan 27 '23 at 18:38
  • 1
    @Laiv good point. Better now? – candied_orange Jan 27 '23 at 18:41
  • I consider a merge conflict a failure of communication, a failure of architecture, or both. Ideally, no two people should have to work on the same file at the same time, and if they do, it will be in two different places in the file so that a merge can happen automatically. – Robert Harvey Jan 28 '23 at 16:49
1

Any time you want to put your changes into the base line, someone might have made different changes.

You want your code to merge without merge conflicts. Actually what you want is that the baseline, combined with your changes, exactly matches your changes because this is what you have tested. The typical sequence:

  1. You branch from the baseline.
  2. You spend say a week to create a new version with your changes.
  3. You merge the baseline into your work, solve merge conflicts, and make all changes needed to make it work again. Say that takes a day.
  4. If there were any changes then go back to Step 3.
  5. Create a pull request. Fix all changes due to comments and have them reviewed, and merge your changes if ther is no merge conflict.
gnasher729
  • 42,090
  • 4
  • 59
  • 119
  • Thanks. 4. If there was any change ... -> if there was a new baseline in the mainline made by collaborators, ..... 5. merge your changes i.e. create a new baseline on the mainline – Tim Jan 28 '23 at 17:06