Source Code Control

Local Version Control System:

• Codebase is maintained locally

Centralized Version Control System (CVCS):

• Code resides on a central base
• Developers:
  • create work branches
  • perform changes on the work branch
  • publish changes to the central base
    • SVN is an example of CVCS

Distributed Version Control System (DVCS):

• Developers:
  • clone the central base into their local machines
  • create work branch from the local base
  • perform the changes in the work branch
  • merge the changes in the work branch to local base
  • synchronize the local base with the central base
    • Git is an example of DVCS

• The Mainline branch must be stable always so that the code is in ready to deploy state.

• Ready to deploy implies that the code has successfully passed tests like integration, regression, and so on.

• Code in mainline is deployed to the user or production environments.

• Change done on the release branch must flow back to the mainline.

• The Release branch should never receive a change from the mainline.

• It must be closed after a release from the mainline.

• Work or development branch is where the developer compiles the code, integrates and runs tests.

• Stable changes in work branches are published to the mainline.

What if your team is implementing multiple changes in parallel on the work branch?

Publishing to the mainline is easy when only one change is implemented at a time.

Consider a scenario when 2 developers are working on the same work branch:

• Developers A and B are working on different changes simultaneously.
• Developer A has partially completed the changes and merges it with the work branch.
• Developer B completes the changes fully and merges it with the work branch.
• Then, developer B publishes the changes to the mainline.
• Accidentally, B ends up publishing the partially done changes of A to the mainline.
• Publishing an incomplete code to the mainline is a violation of the mainline branch policy.
• If an issue arises later, it will be hard to say whose change introduced it.

What can be done now?

How to handle conflicts during code merge?

• Developer A is using a library variable in the code changes.
• Developer B completely removes references to the library and publishes it to the mainline.

Now, developer A needs to discover the conflicting change before proceeding further.

To detect conflicts at an early stage:

• Merge down the code from the work branch to your development region as often as possible
• Check-in changes to the work branch frequently

What if other teams are working on separate work branches that end up publishing to the mainline?

• Merge down changes from the mainline to the work branch, ideally, every day.
• The team that discovers the conflict is responsible for sorting out the conflict.
• Publish changes from the work branch to the mainline regularly.

The team that checks in the changes first is the winner.

A high priority bug got detected post user-release. What has to be done now?

• Create a release branch from the mainline based on the time it was released.

• Fix the bug on the release branch.

• Merge the changes from the release branch with the mainline.

Now that you have learnt briefly about version control, how does CI fit in here?

• Merging or committing changes frequently is a top practice, that lays as a backbone of CI.

• Version control helps a developer to plan and execute changes seamlessly.

Branching helps in parallel development. Work can be done on two or more work streams simultaneously, without affecting one another.

• Physical: Branches created for files, subsystems, and components.

• Functional: Branches created for features, logical changes, bugfixes, and enhancements.

• Environmental: Branches created for build and runtime platforms such as compilers, libraries, hardware, operating systems, and so on.

• Organizational: Branches created for activities/tasks, subprojects, roles, and groups.

• Procedural: Branches created to support policies, processes, and states.

The next few cards will help you understand the various branching techniques that teams will adapt based on their need.

• Branch by Feature

• Branch by Release

• Branch by Team

• Branch by Abstraction

All the 3 types of branches ( mainline , work and release ) discussed in the version control section must be used at appropriate places in each of these techniques.

• Merge mainline onto every branch daily.

• Branches must be short-lived (few days).

• The number of active branches at any time must depend on the number of features that are developed.

• New branch should not be created until the previous branch is merged with mainline.

• Refactorings (changing code without changing the behavior) must be merged immediately to minimize conflicts.

• Used in a large team that works on functionally independent areas.

• The mainline must be in a releasable state.

• Branch is created for every team.

• Merged with the mainline only when the branch is stable.

• Merge done to the mainline from any given branch must be published to every other branch.

• Create small teams with each team working on its own branch.

• Publish changes from the mainline to every branch daily.

• Run unit and acceptance tests for every check-in done to the branch.

• Run all tests (including integration tests) on the mainline every time a branch is merged with it.

• On discovering a bug after merging with the mainline:

  • Perform changes in the team branch and stabilize before merge (or)

  • Create a new branch for bug fixes.

• Trunk (mainline) based development.

• Mainline is always stable and ready for deployment.

• Used for making large-scale changes incrementally.

Stream-based version control is helpful in the following scenarios:

• Applying a bugfix to several versions of the application.

• Adding a new version of a third-party library to the codebase.

How it is done:

• Promote the changes in your stream to the common ancestor of all the streams that need the change.

• IBM Clearcase and AccuRev are popular stream-based version control systems.