Facts:

  • the Carbon console is ugly: the less you see it, the better
  • development and testing are iterative processes: you might need to deploy several versions before everything is OK and you do not want to perform these actions manually
  • you need a simple way to determine which version of the project is in production and be sure that your sources are up to date.

Here is the most straightforward way I found to achieve these goals with Gitlab

Requirements

Besides versioning your ESB projects (in this case, with Gitlab), you will need to take care of the following details

Project structure

The following example requires that the different modules of your projects

  • ESB: ESBConfigProject
  • CA: CompositApplicationProject
  • CE: ConnectorExporterProject
  • REG: RegistryRessourceProject

are explicitly linked in a mavenmultimodule pom.xml. Here is an example of such a pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" 
xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.someCompany</groupId>
  <artifactId>someProject</artifactId>
  <version>1.0.0</version>
  <packaging>pom</packaging>
  <name>someProject</name>
  <description>some description</description>
  <modules>
    <module>someProject_ESB</module>
    <module>someProject_REG</module>
    <module>someProject_CE</module>
    <module>someProject_CA</module>
  </modules>
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-eclipse-plugin</artifactId>
        <version>2.9</version>
        <configuration>
          <buildcommands />
          <projectnatures>
            <projectnature>org.wso2.developerstudio.eclipse.mavenmultimodule.project.nature</projectnature>
          </projectnatures>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

Except for the CompositApplicationProject name of which should end with _CA, you are free to use different names from one project to another provided that all your project share the following folder structure:

[someProject]
    pom.xml (the one above)
    .gitlab-ci.yml (see bellow)
    [someProject_CA]
        pom.xml
        .....
    [someProject_ESB]
        pom.xml
        src
            main
            ....
        .....
    [someProject_CE]
        pom.xml
        .....
    [someProject_REG]
        pom.xml
        .....

Local runners for deployment

You’ll also need on premise gitlab runners (shell type) with write rights on you $WSO2_EI_HOME/repository/deployment/server/carbonapps. That’s all you need. installation details

A look at .gitlab-ci.yml

build_car: 
  stage: build
  image: maven:3.6.3-jdk-8
  only: 
    - master
    - dev
  script: 
    - export CI_PROJECT_NAME
    - echo "Starting build ${CI_PROJECT_NAME}"
    - mvn clean install -Dmaven.test.skip=true -Dversion=$CI_COMMIT_SHORT_SHA
  artifacts:
    paths: 
      - ./*_CA/target/*.car
  tags:
    - docker

dev_deploy:
  stage: deploy
  script: 
    - $carbon_app_name = $(Get-ChildItem ./*_CA/target/*.car).name.split('_')[0]
    - $old = Get-ChildItem  $carbon_app_name*.car -Path "$($env:WSO2_EI_HOME)\repository\deployment\server\carbonapps"
    - if ($old) {rm $old.fullname}
    - $new = Get-ChildItem ./*_CA/target/*
    - Copy-Item -Path $new -Destination "$($env:WSO2_EI_HOME)\repository\deployment\server\carbonapps"
  only: 
    - dev
  tags:
    - wso2
    - esb
    - dev

production_deploy:
  stage: deploy
  script: 
    - $carbon_app_name = $(Get-ChildItem ./*_CA/target/*.car).name.split('_')[0]
    - $old = Get-ChildItem  $carbon_app_name*.car -Path "$($env:WSO2_EI_HOME)\repository\deployment\server\carbonapps"
    - if ($old) {rm $old.fullname}
    - $new = Get-ChildItem ./*_CA/target/*
    - Copy-Item -Path $new -Destination "$($env:WSO2_EI_HOME)\repository\deployment\server\carbonapps"
  only: 
    - master
  tags:
    - wso2
    - esb
    - prod

The following pipeline has two steps.

Build

The build_car job will be realized by shared runners for every new commit on either the dev or master branches. Here, we are using maven:3.6.3-jdk-8 official docker image. Here you probably noticed that we are using -Dversion=$CI_COMMIT_SHORT_SHA during mvn clean install. That’s because we are using variables in pom.xml’s versions, like so:

<project 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" 
xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>com.someCompany</groupId>
    <artifactId>someProject</artifactId>
    <version>1.0.0</version>
  </parent>
  <groupId>com.someCompany.someProject_CA</groupId>
  <artifactId>someProject_CA</artifactId>
  <version>${version}</version>
  <packaging>carbon/application</packaging>
  <name>someProject_CA</name>
  <description>someProject_CA</description>

(you’ll understand later why). Once build, the .car is stored in the project’s artifacts

Deploy

Depending on whether trigged by the dev or prod branch, the success of the build job will trigger the deploy job for the relevant gitlab-runner. In this powershell based example, the runner

  • identifies the project name based on the .car’s name (e.g. someProject_CA_c5ad90bf.car -> someProject)
  • looks for a previous version in $WSO2_EI_HOME/repository/deployment/server/carbonapps
  • removes it
  • and copy the new one