Some best practice to show development methodologies around versioning and continuous operation tools

1. How to work with versioning and CI/CD

2. Index

Intro

Tools

Project Organization

How to work on a new issue

Releases

Deployments

Running pipelines

3. Intro
This handbook focuses on how a developer should work with version control and CI/CD tools.

4. Tools
Let’s say we use Git as a version control system, GitLab as a repository manager and GitLab
CI/CD for the continuous operations and Archiva to store, manage and to browse build artifacts.
Documentation can be found at the following links:
●
Git
●
GitLab
●
GitLab CI/CD

5. Project organization: branches
Basically, when a new project is created from scratch it has 2 main branches: master and develop.
master is the branch containing a more stable code. We can think at master branch as the branch
containing the code that lives in production. It doesn’t contain features under development and
under testing. Here it is how a cloned project looks like during development:

6. Project organization: branches
When a developer starts working on a new task, he creates a new feature branch ad hoc for the
issue. Normally the new branch is named with the word feature followed by the name of the Jira
issue (or sometimes the name of the fix).
The right path is to merge the feature branch to develop (always to develop!) once the work is
done. Next, the code under develop branch can be built and deployed in test environment. Once all
tests are done, the develop branch can be merged into master.
Note: due CI/CD implementation, generally merging a branch into another could have some
consequences, in our environment merging feature branches into develop is totally safe. This
mechanism is explained in the Pipelines chapter.

7. How to work on a new issue: technically speaking

Clone the project from GitLab, or pull (if it has been cloned before on the workstation)
●
Use git pull or git clone

Create a new feature branch from develop.
●
Use git checkout develop, then git checkout -b feature-yourname

Solve the issue

Commit and push your work
●
git add . #adds all local edits to the commit
●
git commit -am “[name of the issue] - commit message”
●
git pull # get remote edits if there are any
●
git push #push your code to remote repository (set upstream and git push -u to push a new
branch to remote)

8. How to work on a new issue: a best practice

Squashing commits with rebase
It is a good practice combining commits into a larger one. Normally when a developer reaches a
stable situation he commits the local work. So when the issue is done the local work contains
multiple commits. It’s a good thing doing a git rebase -i to squash commits into a new base one
before pushing to a remote branch.

9. How to work on a new issue: a requirement

Pull before push, and solve conflicts
When all the work is done and committed, once the developer is ready to push, a pull has to be
done to let Git get to the local repository all the changes others have done. If others have
worked on the same code, Git marks those lines as conflicts, that need to be solved before
pushing.
Conflicts happen also during merge.

10. Releases
When we are ready to apply changes to a service or a service component and deploy it to an
environment as a result of one or more changes, we do a release.
Possible steps to release are:
●
Set a new Maven version
●
Use: mvn versions:set -DnewVersion=x.x.x
●
Create a tag
●
Use git tag -a "x.x.x" -m "last commit message" ; git push --tags
●
Or create tag directly on GitLab using version and last commit message
●
Merge feature branch to develop
●
Deploy to Archiva (if needed)
●
Use mvn deploy
●
Note: Just deploy only the changed module

11. Running Pipelines: actual configuration and monitoring
●
pipelines actually should consist of multiple stages
●
Standard stages are build, test, deploy
●
When there is a push on any branch a pipeline is ran. Go to the GitLab project page, CI/CD→
Pipelines to monitoring the status of the pipeline:
●
Check the status (should be green):
●
Click on the button to see the stages:
●
Click again on the stage button to see the logs
Note:
Official GitLab pipelines documentation .

12. Running Pipelines: goals
The ideal situation for a complete automation is to have a pipeline with 3 stages for all projects,
or at least build and test stage for a good CI/CD implementation. The build stage come for
free, the test stage needs unit tests to be implemented:
●
Build – it runs a mvn clean install
●
Test – it should run unit test normally with mvn verify
●
Deploy (normally only on branch master) – it can move Maven artifacts to some repository, or
jar files to a certain server.
This configuration explains why it is important to have a look at the pipeline configuration
when merging to another branch. As a matter of fact, a merge to master could trigger a
pipeline containing a deploy stage.

13. Running Pipelines: considerations
Pipelines are a good way to have a general projects overview.
As an example changes on a Kafka producer could break a consumer pipeline.