63. devonfw Technologies Templates

63.1. How to add a Template to your PL instance

  • Go to Jenkins.

  • On the upper left click on "New Element" to create a new Jenkins job.

  • Chose a name for the job such as "MTS-template-seed-job". The job type has to be "Pipeline". Click on ok.

newjenkinsjob
  • Scroll down to the bottom of the job creation page where you will find the "Pipeline" section.

    • Switch to "Pipeline script from SCM".

    • Set "SCM" to "Git".

    • Set "Repository URL" to: https://github.com/devonfw/production-line.git

    • Credentials can be left empty, because the repository is public.

    • Set "Script Path" to the template that you want to use e.g. "devon4j-mts/Jenkinsfile".

pipelinesettings
400
400

63.2. devon4j Template for Production Line

63.2.1. Overview

This template will configure your PL instance to have a 'ready to use' devon4j template. It can be used as a starting point for your Java projects.
This includes CICD files for a devonfw technology stack with configuration for:

  • docker or openshift deployment

  • pushing artifacts to nexus3

63.2.2. Prerequisites

To be able to run Jenkins devon4j job under ProductionLine you need to configure below settings in Jenkins and Gitlab

500

Next click on the pen icon

500

On the left menu choose Access Tokens and put token name and check fields like below

600

Click "Create personal access token", you should receive notification about created token and token string. Copy the token string.

800

The GitLab API user needs to have API access and the rights to create a new group. To set this permission follow the next steps:

  • Enter the Admin control panel

  • Select 'Users'

  • Select the user(s) in question and click 'Edit'

  • Scroll down to 'Access' and enable 'Can Create Group'

63.2.3. How to insert the Template

In order to add the template, you can follow the guide.

63.2.4. How to run the Template

  • Build the job with parameters:

    • PROJECT_NAME: The project name.

    • PROJECT_SUFFIX: The project name suffix. As your project can have multiple assets (backend, frontend, middleware…​), you can define a suffix in order to identify each one with a different name

    • DB_TYPE: The type of the database. Possible values: h2|postgresql|mysql|mariadb|oracle|hana|db2

    • GROUP_ID: The group id of the project.

    • GITLAB_USER_PRIVATE_TOKEN: Private Token of a Production Line Gitlab User that can be used to create repositories. Created as prerequisite, you only need to add it as credential with GitLab API token Kind.

    • GITLAB_CREATE_GROUP_NAME: Name of the GitLab group. The repository will be create inside this group.

    • GITLAB_CREATE_PROJECT_DESCRIPTION: Description of the repository.

    • DEPLOY: Choose the environment where you want to deploy. The deployment could be none, docker or openshift. If docker or openshift were selected, extra parameters will be required in their dedicated steps:

      • Configuring DOCKER:

        • DOCKER_URL: The remote docker daemon URL

        • DOCKER_CERT: Credentials to access docker daemon. If the daemon is not secure, you can leave this empty.

      • Configuring Openshift:

        • OC_NAME: Openshift cluster name. It was defined in the Openshift Configuration template

        • DOCKER_REGISTRY_CREDENTIALS: Nexus docker registry user credentials. It was created in the initialize instance pipeline. The default username is nexus-api, the default password is the same as your service account.

After executing this template, you will have:

  • A new GitLab repository.

    • The repository group is the value passed in the GITLAB_CREATE_GROUP_NAME parameter.

    • The repository name is PROJECT_NAME-PROJECT_SUFFIX

    • The repository contains a clean devon4j project.

    • The repository contains a Jenkinsfile.

    • The repository has already setted the jenkins webhook.

    • The repository protects the branches master and release/* to only maintainers to push. Develop is the default branch.

  • A new multibranch pipeline in jenkins inside the folder PROJECT_NAME with the name PROJECT_NAME-PROJECT_SUFFIX. As the webhook is already configured, it should be executed on every push to GitLab repository.

  • If you choose docker for deployment, your Jenkinsfile should contain two extra stages in order to build and deploy the docker image. Also, the repository should contain the Dockerfiles to create the docker images.

  • If you choose OpenShift for deployment, three new applications should be created in your OpenShift. Those applications represent three environments of your application: develop, uat and stage. Also, your Jenkinsfile should contain three extra stages in order to build and deploy the docker image and check that the pod is running without errors. Also, the repository should contain the Dockerfiles to create the docker images.

400
400

63.3. devon4ng Template for Production Line

63.3.1. Overview

This template will configure your PL instance to have a 'ready to use' devon4ng template. It can be used as a starting point for your Angular projects.
This includes CICD files for a devonfw technology stack with configuration for:

  • ProductionLine instance

  • docker or openshift deployment

  • pushing artifacts to nexus3

63.3.2. Prerequisites

To be able to run Jenkins Angular job under ProductionLine you need to configure below settings in Jenkins and Gitlab

500

Next click on the pen icon

500

On the left menu choose Access Tokens and put token name and check fields like below

600

Click "Create personal access token", you should receive notification about created token and token string. Copy the token string.

600

The GitLab API user needs to have API access and the rights to create a new group. To set this permission follow the next steps:

  • Enter the Admin control panel

  • Select 'Users'

  • Select the user(s) in question and click 'Edit'

  • Scroll down to 'Access' and un-tick 'Can Create Group'

63.3.3. How to insert the Template

In order to add the template, you can follow the guide.

63.3.4. How to run the Template

  • Build the job with parameters:

    • PROJECT_NAME: The project name.

    • PROJECT_SUFFIX: The project name suffix. As your project can have multiple assets (backend, frontend, middleware…​), you can define a suffix in order to identify each one with a different name

    • GROUP_ID: The group id of the project.

    • GITLAB_USER_PRIVATE_TOKEN: Private Token of a Production Line Gitlab User that can be used to create repositories. Created as prerequisite, you only need to add it as credential with GitLab API token Kind.

    • GITLAB_CREATE_GROUP_NAME: Name of the GitLab group. The repository will be create inside this group.

    • GITLAB_CREATE_PROJECT_DESCRIPTION: Description of the repository.

    • DEPLOY: Choose the environment where you want to deploy. The deployment could be none, docker or openshift. If docker or openshift were selected, extra parameters will be required in their dedicated steps:

      • Configuring DOCKER:

        • DOCKER_URL: The remote docker daemon URL

        • DOCKER_CERT: Credentials to access docker daemon. If the daemon is not secure, you can leave this empty.

      • Configuring Openshift:

        • OC_NAME: Openshift cluster name. It was defined in the Openshift Configuration template

        • DOCKER_REGISTRY_CREDENTIALS: Nexus docker registry user credentials. It was created in the initialize instance pipeline. The default username is nexus-api, the default password is the same as your service account.

After executing this template, you will have:

  • A new GitLab repository.

    • The repository group is the value passed in the GITLAB_CREATE_GROUP_NAME parameter.

    • The repository name is PROJECT_NAME-PROJECT_SUFFIX

    • The repository contains a clean devon4ng project.

    • The repository contains a Jenkinsfile.

    • The repository has already setted the jenkins webhook.

    • The repository protects the branches master and release/* to only maintainers to push. Develop is the default branch.

  • A new multibranch pipeline in jenkins inside the folder PROJECT_NAME with the name PROJECT_NAME-PROJECT_SUFFIX. As the webhook is already configured, it should be executed on every push to GitLab repository.

  • If you choose docker for deployment, your Jenkinsfile should contain two extra stages in order to build and deploy the docker image. Also, the repository should contain the Dockerfiles to create the docker images.

  • If you choose OpenShift for deployment, three new applications should be created in your OpenShift. Those applications represent three environments of your application: develop, uat and stage. Also, your Jenkinsfile should contain three extra stages in order to build and deploy the docker image and check that the pod is running without errors. Also, the repository should contain the Dockerfiles to create the docker images.

Unresolved directive in production-line.wiki/master-production-line.asciidoc - include::devon4net-pl.asciidoc[leveloffset=2]

400
400

63.4. devon4node Template for Production Line

63.4.1. Overview

This template will configure your PL instance to have a 'ready to use' devon4node template. It can be used as a starting point for your Node projects.
This includes CICD files for a devonfw technology stack with configuration for:

  • ProductionLine instance

  • docker or openshift deployment

  • pushing artifacts to nexus3

63.4.2. Prerequisites

To be able to run Jenkins Node job under ProductionLine you need to configure below settings in Jenkins and Gitlab

500

Next click on the pen icon

500

On the left menu choose Access Tokens and put token name and check fields like below

600

Click "Create personal access token", you should receive notification about created token and token string. Copy the token string.

600

The GitLab API user needs to have API access and the rights to create a new group. To set this permission follow the next steps:

  • Enter the Admin control panel

  • Select 'Users'

  • Select the user(s) in question and click 'Edit'

  • Scroll down to 'Access' and un-tick 'Can Create Group'

63.4.3. How to insert the Template

In order to add the template, you can follow the guide.

63.4.4. How to run the Template

  • Build the job with parameters:

    • PROJECT_NAME: The project name.

    • PROJECT_SUFFIX: The project name suffix. As your project can have multiple assets (backend, frontend, middleware…​), you can define a suffix in order to identify each one with a different name

    • GROUP_ID: The group id of the project.

    • GITLAB_USER_PRIVATE_TOKEN: Private Token of a Production Line Gitlab User that can be used to create repositories. Created as prerequisite, you only need to add it as credential with GitLab API token Kind.

    • GITLAB_CREATE_GROUP_NAME: Name of the GitLab group. The repository will be create inside this group.

    • GITLAB_CREATE_PROJECT_DESCRIPTION: Description of the repository.

    • DEPLOY: Choose the environment where you want to deploy. The deployment could be none, docker or openshift. If docker or openshift were selected, extra parameters will be required in their dedicated steps:

      • Configuring DOCKER:

        • DOCKER_URL: The remote docker daemon URL

        • DOCKER_CERT: Credentials to access docker daemon. If the daemon is not secure, you can leave this empty.

      • Configuring Openshift:

        • OC_NAME: Openshift cluster name. It was defined in the Openshift Configuration template

        • DOCKER_REGISTRY_CREDENTIALS: Nexus docker registry user credentials. It was created in the initialize instance pipeline. The default username is nexus-api, the default password is the same as your service account.

After executing this template, you will have:

  • A new GitLab repository.

    • The repository group is the value passed in the GITLAB_CREATE_GROUP_NAME parameter.

    • The repository name is PROJECT_NAME-PROJECT_SUFFIX

    • The repository contains a clean devon4node project.

    • The repository contains a Jenkinsfile.

    • The repository has already setted the jenkins webhook.

    • The repository protects the branches master and release/* to only maintainers to push. Develop is the default branch.

  • A new multibranch pipeline in jenkins inside the folder PROJECT_NAME with the name PROJECT_NAME-PROJECT_SUFFIX. As the webhook is already configured, it should be executed on every push to GitLab repository.

  • If you choose docker for deployment, your Jenkinsfile should contain two extra stages in order to build and deploy the docker image. Also, the repository should contain the Dockerfiles to create the docker images.

  • If you choose OpenShift for deployment, three new applications should be created in your OpenShift. Those applications represent three environments of your application: develop, uat and stage. Also, your Jenkinsfile should contain three extra stages in order to build and deploy the docker image and check that the pod is running without errors. Also, the repository should contain the Dockerfiles to create the docker images.

400
400

63.5. From existing devonfw Template for Production Line

63.5.1. Overview

From existing devonfw template is very similar to devon4j, devon4ng, devon4net and devon4node templates. The main difference is from existing devonfw template will no create a new devonfw project, it takes an existing project from GitLab and then add/create everything in order to apply a CICD strategy to your project.

63.5.2. Prerequisites

To be able to run Jenkins Node job under ProductionLine you need to configure below settings in Jenkins and Gitlab

  • Jenkins

  • Gitlab

    • Create a project and upload your current code. In order to start a new project in your local machine, you can use the devonfw-ide. The project must be a devon4j, devon4ng, devon4net or devon4node project.

    • Generate User Private Token
      Go to your Profile in Gitlab

500

Next click on the pen icon

500

On the left menu choose Access Tokens and put token name and check fields like below

600

Click "Create personal access token", you should receive notification about created token and token string. Copy the token string.

600

The GitLab API user needs to have API access and the rights to create a new group. To set this permission follow the next steps:

  • Enter the Admin control panel

  • Select 'Users'

  • Select the user(s) in question and click 'Edit'

  • Scroll down to 'Access' and un-tick 'Can Create Group'

63.5.3. How to insert the Template

In order to add the template, you can follow the guide.

63.5.4. How to run the Template

  • Build the job with parameters:

    • REPOSITORY_URL: The internal repository URL. Without protocol. Example: gitlab-core:80/gitlab/mygroup/myproject-frontend.

    • GIT_BRANCH: The branch where you want to apply the CICD changes.

    • MERGE_STRATEGY: Choose the merge strategy for cicdgen. For more information see the CICDGEN merge documentation page

    • GITLAB_USER_PRIVATE_TOKEN: Private Token of a Production Line Gitlab User that can be used to create/update repositories. The token proprietary user must have admin rights in the repository. Created as prerequisite, you only need to add it as credential with GitLab API token Kind.

    • DEPLOY: Choose the environment where you want to deploy. The deployment could be none, docker or openshift. If docker or openshift were selected, extra parameters will be required in their dedicated steps:

      • Configuring DOCKER:

        • DOCKER_URL: The remote docker daemon URL

        • DOCKER_CERT: Credentials to access docker daemon. If the daemon is not secure, you can leave this empty.

      • Configuring Openshift:

        • OC_NAME: Openshift cluster name. It was defined in the Openshift Configuration template

        • DOCKER_REGISTRY_CREDENTIALS: Nexus docker registry user credentials. It was created in the initialize instance pipeline. The default username is nexus-api, the default password is the same as your service account.

After executing this template, you will have:

  • Your GitLab project updated.

    • Added a Jenkinsfile with all CICD stages.

    • The repository is updated in order to have the jenkins webhook.

  • A new multibranch pipeline in jenkins inside the folder PROJECT_NAME with the name PROJECT_NAME-PROJECT_SUFFIX. As the webhook is already configured, it should be executed on every push to GitLab repository.

  • If you choose docker for deployment, your Jenkinsfile should contain two extra stages in order to build and deploy the docker image. Also, the repository should contain the Dockerfiles to create the docker images.

  • If you choose OpenShift for deployment, three new applications should be created in your OpenShift. Those applications represent three environments of your application: develop, uat and stage. Also, your Jenkinsfile should contain three extra stages in order to build and deploy the docker image and check that the pod is running without errors. Also, the repository should contain the Dockerfiles to create the docker images.

Last updated 2021-03-17 08:55:56 UTC