Author: Ashutosh Kumar
Introduction:
This guide is about the CI/CD (Continuous Integration/Continuous Delivery) pipeline and How to deploy domain projects jar for the maven reference in the Package Registry of the GitLab. CI/CD, or continuous integration and continuous delivery, is the practice of building and releasing software in an automated and safe manner.
Prerequisites:
- GitLab Account
- Anypoint Platform Account
- Standalone Mule Server
- Container Registry eg. Nexus, jFrog, etc (if using maven dependencies which are not found in .m2/repository)
Note: If the client account does not have a Nexus Repository, Then we can raise the request in the mulesoft support to get a Nexus Repository for free.
As shown Below:
Objective:
- To deploy a domain project to the package registry of the GitLab.
- To deploy a MuleSoft application having a domain project to Anypoint Platform using Mule Standalone Server with GitLab Pipeline.
Steps to deploy domain project in package registry:
- Create an empty project and name it Package Registry.
- Go To the Repository in the Settings and expand the Deploy Token sections, Fill the name, expire at(if not provide token will remain active until deleted exclusively) properties and create a token.
- And save the token externally as it will not be shown again.
- The deployment token can be created from a personal account also. Go to the drop down user on the top right corner -> preferences -> Access Token.
- Authenticate to the Package Registry with Maven
Add the following credentials in the settings.xml of the maven.
1. Authenticate with a personal access token in Maven
To use a personal access token, add this section to your settings.xml file. The name must be Private-Token.
2. Authenticate with a deploy token in Maven
To use a deploy token, add this section to your settings.xml file. The name must be Deploy-Token.
- Use the GitLab endpoint for Maven packages
To use the GitLab endpoint for Maven packages, choose an option:
- Project-level: To publish Maven packages to a project, use a project-level endpoint. To install Maven packages, use a project-level endpoint when you have few Maven packages and they are not in the same GitLab group.
- Group-level: Use a group-level endpoint when you want to install packages from many different projects in the same GitLab group.
- Instance-level: Use an instance-level endpoint when you want to install many packages from different GitLab groups or in their own namespace.
The option you choose determines the settings you add to your pom.xml file.
In all cases, to publish a package, you need:
- A project-specific URL in the distributionManagement section.
- A repository and distributionManagement section.
1. Project-level Maven endpoint
The relevant repository section of your pom.xml in Maven should look like this:
- The id is what you defined in settings.xml.
- The PROJECT_ID is your project ID, which you can view on your project’s home page.
- Replace gitlab.example.com with your domain name.
- For retrieving artifacts, use either the URL-encoded path of the project (like group%2Fproject) or the project’s ID (like 42). However, only the project’s ID can be used for publishing.
2. Group-level Maven endpoint
If you rely on many packages, it might be inefficient to include the repository section with a unique URL for each package. Instead, you can use the group-level endpoint for all the Maven packages stored within one GitLab group. Only packages you have access to are available for download.
The group-level endpoint works with any package names, so you have more flexibility in naming, however, GitLab does not guarantee the uniqueness of package names within the group. You can have two projects with the same package name and package version. As a result, GitLab serves whichever one is more recent.
This example shows the relevant repository section of your pom.xml file. You still need a project-specific URL for publishing a package in the distributionManagement section:
- For the id, use what you defined in settings.xml.
- For GROUP_ID, use your group ID, which you can view on your group’s home page.
- For PROJECT_ID, use your project ID, which you can view on your project’s home page.
- Replace gitlab.example.com with your domain name.
- For retrieving artifacts, use either the URL-encoded path of the group (like group%2Fsubgroup) or the group’s ID (like 12) (as shown in the above image)
- Publish a package
After you have set up the remote and authentication and configured your project, publish a Maven package to your project.
1. Publish by using Maven
To publish a package by using Maven:
If the deploy is successful, the build success message should be displayed as follow and the message should also show that the package was published to the correct location:
Once the package is deployed, we can take the dependency to install the jar from the project/group package registry as shown below:
Steps to deploy a MuleSoft application to Anypoint Platform using Mule Standalone Server with GitLab Pipeline:
Before starting the server, download the domain project .jar file from the package registry and place your domain project jar inside the domain folder of your runtime(if any).
Create a develop branch in the project and check in the following folders and file in the project repository.
Once the branch is created, go to settings -> repository -> protected branches, And add the branch/branches to the protected branches so that whenever we create a pipeline variable, it allows us to mask the variable.
Open the pom.xml of the project and add the armDeployment properties in the configuration for the Standalone/Hybrid Deployment Model.
Create a .gitlab-ci.yml file as the Gitlab CICD automatically detects the pipeline file.
Within the .gitlab-ci.yml file write the following pipeline code:
image: maven:3.5.2
a. The values of username, password, environment, businessGroup, mule_env_build and mule_key_build are taken from the group variable(go to group-> settings -> CICD ->Variable) and make sure that the variable values are masked and protected (If the branches are protected then only it will take values of the variable from the defined pipeline variable).
b. The values of mule.env and key for the API level encryption and decryption have to be defined in the wrapper.conf of the Mule Runtime. (As well as the values for anypoint clientId/ ClientSecret and anypoint URL)
c. The build stage will execute for each environment and rules for each environment if different:
i. Develop Environment:
1. If the commit is made in the develop branch then only it will automatically start the pipeline deployment for the development environment.
ii. Staging Environment:
1. If the commit is made in the staging environment or the trigger source is from the staging environment then only it will run the staging deployment but will need a approval to start the deployment as the method to deploy in staging is “Manual” as show in the image below:
iii. Production Environment:
1. Once the code is merged from the staging branch to the mainbranch, the build of the project will run automatically and once the build stage is successful, it will need approval to deploy the code from the production pipeline to the Mule Runtime as the method of deployment over here is also “Manual”.
