Technical documentation

The NetYCE development team uses cycles of about two weeks to create software builds. These builds come in two types, general and preliminary releases. The general releases are fully tested whereas the preliminary releases have undergone only integration testing.

General release packages (or builds) can be deployed on production NetYCE servers, the preliminary packages are intended for non-production deployments for the lab or (acceptance) testing. It is essential for multi-server NetYCE installations that all servers run the same version and build.

To allow major new feature development without disrupting support fixes and the gradual enhancement development, NetYCE uses various development branches which are maintained using GIT repositories by Github.

Each branch forms a copy of the codebase that is extended or modified by the developers to create a feature or fix issues. These branches can and must be merged with another branch to create an integrated codebase. A scrict 'flow' of code changes is essential to ensure fixed problems stay fixed and enhancements can be properly integrated and tested.

The NetYCE organisation of branches and their 'flow' has resulted in a process that ensures a continuous cycle of preliminary and general release builds can be created. This 'incremental' form of releases offers the benefit of fast responses to issues or customer requests.

The revision number associated with each build (e.g. 7.0.4 and 7.1.0) forms therefore more of an indication of the incorporated set of features rather than a fixed set of fixes and enhancements. It is the build number (e.g. 20180711) that has this information. These build numbers are formed by its creation date so that the higher (or later) build ensures a more recent set of fixes and enhancements, the prefixed version number is of lesser relevance.

The (simplified) NetYCE development branching setup and resulting release schema is shown in this sample diagram.

From this diagram it can be observed that there are two persistent major branches and several optional feature branches. The guidelines pertaining to these branches are as follows:

• Master
  • is stable branch
  • creates general release packages
  • has release tags
  • only the Development branch can merge into Master
  • is used to test general release packages
  • will never terminate
• Development
  • is the main development branch
  • creates preliminary packages
  • performs integration role for feature branches
  • primary support branch
  • will never terminate
• <feature>
  • development for feature only
  • can only merge into Development
  • cannot create packages
  • will terminate on final merge