During this round you will learn to use version control in team work and integrate the work of team members together with version control.
After the round you are able to explain how version control works as a key tool in software development.
You will also learn to use commenting program code as a documentation tool and to explain how different tools help to make work more fluent and in supporting communication.
So far the course has focused on the programming language level solutions for developing programs in parts with several programmers.
In addition to the programming language tools and processes are needed in order to keep the project headed to the right direction and for the pieces implemented by many programmer to integrate into a complete piece of software.
To make this possible, version control plays an important role.
In software project work a group of basic tools play a central role in supporting the programming work itself
as well as team work as a whole.
Due to agile development methods the need for a fast development cycle has increased and this in turn has emphasized the need to tools that support agile software development all the way to deployment into production.
For iterative and agile development to be possible the software must stay functional as a whole.
When a team of people is developing the software each are responsible for components that call eachother’s services through interfaces, the software as a whole needs to be built regularly.
Today a good basis for development is that the software is kept integrated and deployable during the entire development lifecycle.
The goal is continuous integration where members of the team integrate the code they have developmed together several times a day.
Continuous integration is not a new invention:
Grady Booch suggested the term continuous integration as early as 1991 and it is included in the software development method Extreme Programming that incorporates many key practices known in software development today.
Version control is one of the most integral tools in software development when the coding effort of more than one developer is needed.
In the remote repository the softwar is kept integrated as a whole.
Whenever an individual developer starts the implementation of a new feature, the project of the developer branches from the rest of the project.
The longer the developer’s work stays separate from the rest of the code, the more likely it is for the development to and in a situation where the code developed no longer integrates into the project without problems.
The worst case is to end up in so called integration hell where piecing the project together takes more work than the development of the feature did.
This can be avoided when the code developed is integrated into the entire project regularly and frequently.
Testing and integration are automated so that each push to a specific branch in the remote repository trigger the build and testing of the entire software project¶
Continuous integration is not core knowledge on the course.
It is covered thoroughle in Software Product and Process Management among other software process courses.
Yet it is important to remember from the beginning that several team members are working with the project in version control and what you are doing affects others.
A startin point for work is where
Each completed functionality is tested thoroughly locally before pushing it into the remote repository
The complete software project is kept fully integrated in the remote repository
(The code pushed into the remote repository is tested and integrated automatically)
Every programmer commits code into the mainline in the remore repository as it is completed, i.e. daily
If broken code is pushed into the remote repository, it is fixed immediately
The role of version control when developing software as a team is integral: all code is integrated (and tested) through version control.
James Shore’s blog post Continuous Integration on a Dollar a Day is an old but valid desrciption on
how continuous integration does not require major tools but is based mainly on the team working according to shared principles.
Martin Fowler’s blog post Continuous Integration is a good walkthrough od the basics.
Jez Humble and David Farley’s book Continuous Delivery and its chapter on the toolchains for continuous integration give an excellent
basis for the topic.