Checkout, Change and Build

We use the so-called 'git-flow' workflow, which is described in detail here and here. The main idea:

  • The master-branch contains only released code, no changes are made here except by pull-requests from release-branches or hotfix-branches. The master-branch contains regular non-snapshot versions, such as 1.2.6, with typically a single release every week.
  • The develop-branch is where all the development is happening, however for all changes we use feature-branches, which are then merged into the develop-branch. This keeps the develop-branch relatively clean and stable, as only feature-branches are merged that are 'ready', even if it's a very small change. The develop-branch contains snapshot-versions, such as 1.2-SNAPSHOT which is used for multiple weekly releases.

The following sections describe typical actions in the development process.

Clone a remote repository

  1. Clone the remote repository. Typically this automatically checks out the default branch (e.g. develop)
git clone https://github.com/trimplement/cw-core-backend
  1. Create a file '.gitignore' with the following contents in the root folder of the local repository for backend projects
target
.*
  1. Create a file '.gitignore' with the following contents in the root folder of the local repository for frontend projects
node_modules
vendor
dist
bower_components
  1. Checkout the following two remote branches, so they are available locally, if they are not yet locally available
    1. master
git checkout master
  1. develop
git checkout develop
  1. Initialize the git-flow for the repository with the default settings
git flow init

Make a change

All changes should be made with a feature-branch that is branched off the 'develop'-branch.

  1. Checkout the 'develop' branch and update to the latest commit
git checkout develop
git pull
  1. Create the feature-branch using git-flow, and give it a proper name (this name will be used as part of the branch name, and later in the merge-back-commit-message!)
git flow feature start myfeature
  1. Checkout the new feature-branch (if not done automatically)
git checkout feature/myfeature
  1. Make the change, possibly using multiple commits
git add .
git commit -m "My commit message"
  1. When done with the implementation (and ready to merge it back into develop), pull changes from the remote repository to your local repository for the 'develop' branch - this prevents unnecessary and ugly merge-commits
git checkout develop
git pull
  1. Once finished, merge the feature-branch back into your local 'develop' branch
git flow feature finish myfeature
  1. Push the change to 'origin/develop' to make the commit available in GitHub repository, so that the build-server can build it
git push

Optionally one can also push the feature-branch to 'origin' so that other people can also work on it. From that moment one cannot use rebase anymore though to interleave newer commits.

Build process

This section describes the build process for the CoreWallet.

Local build (backend)

A local copy of the CoreWallet source code can be built using the following command:

mvn clean install

It compiles the sources, runs the unit-tests and creates the JAR-files, including sources and JavaDoc.

To build with integration tests (which include DAO tests and internal security tests), use the following command:

mvn clean install -Dintegration-tests

To generate the aggregate JavaDoc for the CoreWallet, use the following command:

mvn javadoc:aggregate

Continuous Integration

A build server can be setup (e.g. Jenkins) which monitors the Git repositories and builds whenever a new commit is available. It can be extended to automatically build the product repository afterwards, and deploy the product to a development system.

Periodically a job can run to analyse the source code and publish the results to a SonarQube system.