Newer
Older
## Building Code and Continuous Integration
### Building Code
To get a software running, build tools `SHOULD` be used.
The reason for this is to be able to build and/or test a code project with one command (after checking
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
out). Another reason is to include dependency management.
#### Build tools we are using at the moment
- **bash scripting**: (bdnPrint, FontanePrint)
- **eXist**: Ant (SADE)
- **Java**:
- Maven (TextGrid)
- gradle (TextGrid)
- **JavaScript**:
- bower (DARIAH-DE GeoBrowser, tgForms)
- cake (tgForms)
- NPM (DARIAH-DE Publikator, tgForms)
- rake (DARIAH-DE GeoBrowser)
- **Python**:
- make (Sphinx documentation)
- PIP (DiscussData)
- **Ruby**: bundler (DARIAH status page)
### Packaging
#### CESSDA's Software Maturity Levels in RDD (CA5)
##### MUST
`MUST` be SML5, which is defined as follows:
> Demonstrable usability: A Continuous Integration server job (or equivalent) is available to deploy the
packaged/containerised software. Administrators are notified if deployment fails. Versions of deployed software can be
upgraded/rolled back from a Continuous Integration server job (or equivalent). Data and/or index files can be restored
from a Continuous Integration server job (or equivalent).
##### Actions to Be Taken in RDD
- examples for versions of deployed software: versioning of deb packages
- examples for rollback: rebuild index ElasticSearch from source data, restore database backup
### Continuous Integration
We want to use CI as soon as possible in new projects. Please set up your GitLab project to show your pipeline-status
and test-coverage for your default-branch under Settings/General->Badges.
The generic links for all projects are:
- Pipeline-status
- Link: `https://gitlab.gwdg.de/%{project_path}/commits/%{default_branch}`
- Badge image URL: `https://gitlab.gwdg.de/%{project_path}/badges/%{default_branch}/pipeline.svg?style=flat-square`
- Test-coverage
- Link: `https://gitlab.gwdg.de/%{project_path}/commits/%{default_branch}`
- Badge image URL: `https://gitlab.gwdg.de/%{project_path}/badges/%{default_branch}/coverage.svg?style=flat-square`
The workflows we are using currently in Jenkins and GitLab Runner are:
- Code building
- Testing
- Code analyzer (Sonar)
- Packaging (JAR, WAR, DEB, XAR)
- Distribution (Nexus, APTLY repo, eXist repo)
- Release Management (via GitLab Environments and gitflow)
#### Sample Configuration of the GitLab Runner
There is a [full and documented example](https://gitlab.gwdg.de/SADE/SADE/blob/develop/.gitlab-ci.yml) of how the
GitLab Runner is used in SADE.
#### Sample Configuration of the Jenkins CI (Multibranch Pipelines)
- On commit and push to the <https://projects.gwdg.de> gitolite repo (such as
<https://projects.gwdg.de/projects/tg-crud/repository>) Jenkins on [ci.de.dariah.eu](https://ci.de.dariah.eu/jenkins)
is notified (see projects' gitolite configuration)
- Jenkins then checks out and builds the configured branches (see Jenkins' project's multibranch pipeline
configuration such as <https://ci.de.dariah.eu/jenkins/job/DARIAH-DE-CRUD-Services>.
- Stage *Preparation*: Prepare things
- Stage *Build*: Build, JAR, WAR, and DEB packages from source code, deploy JAR and WAR packages to the [Nexus
repo](https://nexus.gwdg.de). For further information on Nexus cf. [ci's server
documentation](https://wiki.de.dariah.eu/display/FEAD/ci.de.dariah.eu). Jenkins is configured to deploy JARs and WARs
via Maven and a Nexus deploy-account.
- Stage *Publish*: Publish DEB packages to the [DARIAH-DE Aptly Repo](https://ci.de.dariah.eu/aptly). Jenkins is using
a shared library of scripts and publishing is devided into four conditionals: TG version, DH version, SNAPSHOT version,
or RELEASE version due to given version suffixes!