SCM:

Software Configuration Management

Rationale

Software Development is a very dynamic task:

- Multiple versions (even in parallel)

- Updates to users

- Multiple Devs

- New Reqs (e.g. agile)

Every day the need of having continuous updates / versions is higher (everything is connected, higher BW, social networks...)

SCM is the discipline that helps us to deal with this dynamism:

Software Versions are properly managed even in parallel
Different people can work in the same software project
Issues (Bugs, Features, User Stories...) are tracked
Software changes are tracked and can be related to issues
The software development process follows a set of rules
Software releases and deliveries are properly managed

SCM is also used to refer to Source Code Management

Git, SVN are pure Source Code Management tools that focus on keeping track of items but do not provide the rest of the tools required for Software Configuration Management

SCM: Example Tools

There are multiple tools and combination of them to be used for SCM. The key aspect is to define how the tools are orchestrated.

Example:

- use GIT for Source Code Management

- use GIT or Redmine for Issue Tracking (Bugs, Features...)

- use Trello for Agile Management

- use Travis for Continuous Integration

The important thing is the relationship across them

Source Code Managment

Tools that help us to control the version of the artifacts that we use to create software: source code, documentation, tests, etc.

For instance, Git is a very successful Source Code Management tool that was developed by Linus Torvalds. If you want to know more about Git you can watch Mr. Torvalds talking about it:

https://www.youtube.com/watch?v=4XpnKHJAok8

Repository

Is a system that stores the different versions of all the configuration items. The repository remembers every change ever written to it: every change to every configuration item and changes on the repository structure (such as the addition, deletion and rearrangement of files and directories)

Centralized vs. Distributed

There's one special repository that is the central one. The rest of the repositories connect only to it (Example: Subversion)

From a technical point of view, all the repositories are equally important and can connect. Sometimes one of them becomes the official repository, but it just a convention (Example: Git)

Workspace & Synchronization

User A Repository

User A Workspace

clone

fork

push

pull

push

pull

pull request

pull

Revisions

Different systems have different approaches with regards to configuration item versioning and identification

In Git, every time code is changed (commit) a revision is created. A revision is linked to a hash code that uniquely identifies a snapshot of the repository at a given moment

Commit

Revision

Commit

Revision

Branches and Tags

A Git branch is an independent line of development.

Branches are used to work on new features, bug fixes, etc. in an isolated way to the main work (master branch) or to other team members work.

Branches can be created from the master branch or from other branches as from a Git internal point of view, they are just additional information about the repository.

Tags are labels assigned to snapshots of a repository on a given moment to identity them better (e.b. v1.0, v1.1, etc.)

Merging

Merging is the task of combining different branches into a single one

Merging is used, for instance, when the work in one branch has finished (e.g. a bug has been fixed in a separate branch) and we want that work to be part of the main (master) branch.

Merging can lead to conflicts if a modified file in the created branch has been also changed in the master branch in the meantime. It's important to pay attention to conflicts.

Tips for Branching

Try always to work in separated branches to master, either for features or bug fixes
Try to make the branches as short-lived as possible:
- Merge to master as soon as you can
- Keep work in as small increments as possible (the smaller items you develop, the better)
- You don't need to merge something perfect (it's acceptable to have known bugs/limitations) if they are tracked (regressions shouldn't be allowed)
- Before requesting a merge sync your branch with master and test again
If you have a branch that needs to be live for a long period, try to sync with the master branch frequently so your branch anticipates to future conflicts and you do it in small pieces rather than in a big final conflict

Continuous Integration and Building

Continuous Integration (CI) is a software development practice where members of a team commit their work frequently, leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. This approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.

Tools

Build Process

Building is the process of getting the sources turned into a running system.

This can often be a complicated process involving compilation, moving files around, generating configuration files, loading schemas into the databases, and so on.

However this process can (and as a resullt should) be automated.

Build Process

(another definition - Facebook)

Build Process - Characteristics

The full build process should be 100% automated

Try to minimize the time required to build your software

Have a centralized build system

However, developers should be able to create IDENTICAL builds locally so they can build and test locally first

Build Process -

Importance of speed (Facebook)

Self-Building and Self-Testing the keys to CI

Every time code is committed to the repository, a build is generated automatically

Every time a build is generated is automatically tested to verify the software works as expected

Everyone in the project should have access to all the builds and the build status (test status) of all the builds.

https://treeherder.mozilla.org/#/jobs?repo=mozilla-central

Mainline cannot be broken

It's good to merge into the mainline very frequently

But that doesn't mean it's OK to accept regressions in the main development branch

When a build is broken (tests are red), the commit should be automatically backed-out

Sometimes there are pre-commit strategies to avoid the need of a back-out by impeding the commit if tests are not green

Releasing

Releasing is the act of delivering a new version of a software product to the customers so they can use it

Every day, there is an increasing need to release frequently new versions, to the end-users. They are usually demanding new features and if you don't implement them a competitor will do.

But shipping (releasing) frequently is not only good for the end-users, it's also good for a company to learn from them