{"id":2041,"date":"2019-09-04T11:44:47","date_gmt":"2019-09-04T09:44:47","guid":{"rendered":"https:\/\/www.thecodecampus.de\/blog\/?p=2041"},"modified":"2025-11-04T11:22:18","modified_gmt":"2025-11-04T10:22:18","slug":"jenkins-vs-gitlab-ci","status":"publish","type":"post","link":"https:\/\/www.thecodecampus.de\/blog\/jenkins-vs-gitlab-ci\/","title":{"rendered":"Jenkins vs. Gitlab CI"},"content":{"rendered":"

\"\"<\/a><\/p>\n

With Gitlab CI going full steem ahead following their proclaimed vision, we want to have a look on it ourselves! Mostly working with the proven and beloved open source CI tool Jenkins, we are wondering, will Gitlab give us some new features and benefits or will it not be able to replace Jenkins as the number one CI-tool. Lets get into it.<\/p>\n

 <\/p>\n

TL;DR<\/strong>
\nWe migrated some CI pipelines from Jenkins to Gitlab CI. We really like the visualization of the different jobs in Gitlab CI. It makes the build jobs more transparent and flexible to use. Performancewise there are no big differences with the medium sized projects we tested it on. For very big and complex projects, things might look a little bit different, as Gitlab stores the job artifacts online and therefore has to up- and download them for every job. So in conclusion it depends on the type of project, but Gitlab is definatly an option to consider.<\/p>\n

Jenkins<\/h3>\n

To set up Jenkins you need an existing installation and a activated pipeline plug-in. The first step is of course the definition of the source-repo, as Jenkins doesn’t provide repositories and connects with other services like Gitlab or Github.<\/p>\n

The next step is the configuration of the pipline-stages. Jenkins needs a speciel file in the repository with the name of jenkinsfile<\/em>. The phases and stages of the build configuration are maintained in this file. Here is an example of a configuration in this format:<\/p>\n

pipeline {\r\n    agent any\r\n    stages {\r\n        stage('Build') {\r\n            steps {\r\n                echo 'Building..'\r\n                nodejs('node 10.9.0') {         \r\n                    dir('www.thetestcompany.de') {\r\n                        echo 'Building Job One'\r\n                    }\r\n                    dir('mail.thetestcompany.de') {\r\n                        echo 'Building Job Two'\r\n                    }\r\n                }\r\n            }\r\n        }\r\n        stage('Test') {\r\n            steps {\r\n                echo 'Testing..'\r\n            }\r\n        }\r\n        stage('Deploy') {\r\n            steps {\r\n                echo 'Deploying....'\r\n                nodejs('node 10.9.0') {\r\n                    dir('mail.thetestcompany.de') {\r\n                        withCredentials([file(credentialsId: params.CREDENTIAL_ID, variable: 'ormconfig')]) {\r\n                            sh \"cp --update -rf \\$ormconfig ormconfig.json\"\r\n                            sh \"npm run migrate:run\"\r\n                        }\r\n                       echo 'Deploying Job One'\r\n                    }\r\n                    dir('www.thetestcompany.de') {\r\n                        echo 'Building Job Two'\r\n                    }\r\n                }\r\n            }\r\n        }\r\n    }\r\n}\r\n<\/pre>\n
A plus is, that the Jenkins script is quiet readable and well structured. Additionally it is possible to use plug-ins, like the withCredentials Command. This makes it possible to include hidden Authentification Credentials in the script.<\/p>\n
When the pipline runs through, we get to check if the stages passed or failed (in that case red colour) as a whole. Unfortunately we can’t see the status of the individual jobs in the graphical overiew. You can follow the progress in the terminal though.<\/p>\n
\"\"<\/a><\/p>\n
Gitlab<\/h3>\n
Gitlab offers repositories. Hence the integration of Gitlab CI is pretty straight forward. Stages and jobs are described in the gitlab-ci.yml configuration file. If you look, the stages command includes a sequence of stages that will be executed in the specified order. After that, every job is described and configured with different options. Every job is part of a stage and will run parallel with other jobs in the same stage.<\/p>\n
image: trion\/ng-cli-karma\r\n\r\nstages: \r\n - build step one \r\n - build step two \r\n - test - migrate \r\n - deploy \r\n\r\n# Extensions \r\n.ssh: \r\n before_script: \r\n   - mkdir -p ~\/.ssh \r\n   - chmod 700 ~\/.ssh \r\n   - echo -e \"Host *\\n\\tStrictHostKeyChecking no\\n\\n\" > ~\/.ssh\/config \r\n   - echo \"$KEY_STAGING\" > ~\/.ssh\/id_rsa \r\n   - chmod 600 ~\/.ssh\/id_rsa \r\n.runner_tags: \r\n  tags: \r\n   - docker \r\n   - linux \r\n#Build Stage \r\nbuild-www.thetestcompany.de: \r\n  extends: \r\n   - .runner_tags stage: \r\n  stage: build step one \r\n  before_script: \r\n    - cd www.thetestcompany.de \r\n  script: \r\n    - echo 'Build Step One' \r\n  after_script: \r\n    - cd .. \r\n  artifacts: \r\n   paths: \r\n    - www.thetestcompany.de\/ \r\n   name: \"Build TTC step one\" \r\n   expire_in: 1 week \r\n   when: on_success \r\n  cache: \r\n   paths: \r\n    - node_modules\/ \r\nbuild-www.mail.thetestcompany.de: \r\n  extends: \r\n   - .runner_tags stage: build step two \r\n  dependencies: [build-www.tcc-core.de] \r\n  needs: [build-www.tcc-core.de] \r\n  before_script: \r\n   - cd www.thecodecampus.de \r\n  script: \r\n   - echo 'Build Step Two' \r\n  after_script: \r\n   - cd .. \r\n  artifacts: \r\n   paths: \r\n    - www.mail.thetestcompany.de\/ \r\n   name: \"Build www.ttc.de\" \r\n   expire_in: 1 week \r\n   when: on_success \r\n\r\n#Test Stage \r\ntest: \r\n  stage: test \r\n  script: \r\n   - echo 'Testing..' \r\n  tags: \r\n   - docker \r\n   - linux \r\n\r\n#Migrate Stage - STAGING \r\nmigrate-www.mail.thetestcompany.de-STAGING: \r\n  extends: \r\n   - .runner_tags \r\n   - .ssh  \r\n  stage: migrate \r\n  image: kroniak\/ssh-client \r\n  script: \r\n   - echo 'Migrate DB' \r\n  after_script: \r\n   - cd .. \r\n  artifacts: \r\n   paths: \r\n    - www.mail.thetestcompany.de\/ \r\n  environment: staging \r\n  needs: \r\n   - www.mail.thetestcompany.de \r\n  dependencies: \r\n   - www.mail.thetestcompany.de \r\n \r\n#Migrate Stage - PROD \r\n\r\nmigrate-www.mail.thetestcompany.de: \r\n  extends:\r\n   - .runner_tags \r\n   - .ssh stage: migrate image: kroniak\/ssh-client script: \r\n   - echo 'Migrate DB' \r\n  after_script: \r\n   - cd .. \r\n  artifacts: \r\n   paths: \r\n    - www.mail.thetestcompany.de\/ \r\n  needs: \r\n   - build-www.mail.thetestcompany.de \r\n  dependencies: \r\n   - build-www.mail.thetestcompany.de \r\n  when: manual \r\n  only: \r\n   - master environment: staging \r\n\r\ndeploy-www.thetestcompany.de-STAGING: \r\n  extends: \r\n   - .runner_tags \r\n   - .ssh \r\n  stage: deploy \r\n  image: kroniak\/ssh-client \r\n  script: \r\n   - cd www.thetestcompany.de \r\n   - echo 'Deploy Job One' \r\n  after_script: \r\n   - cd .. environment: staging \r\n  needs: \r\n   - build-www.thetestcompany.de \r\n  dependencies: \r\n   - build-www.thetestcompany.de \r\n\r\ndeploy-www.mail.thetestcompany.de-STAGING:\r\n  extends: \r\n   - .runner_tags \r\n   - .ssh \r\n  stage: deploy \r\n  image: kroniak\/ssh-client \r\n  script: \r\n   - cd www.mail.thetestcompany.de \r\n   - echo 'Deploy Job Two' \r\n  after_script: \r\n   - cd .. \r\n  environment: staging needs: \r\n   - build-www.mail.thetestcompany.de \r\n  dependencies: \r\n   - build-www.mail.thetestcompany.de\r\n\r\ndeploy-www.thecodecampus.de: \r\n  stage: deploy \r\n  extends: \r\n   - .runner_tags \r\n   - .ssh \r\n  image: kroniak\/ssh-client \r\n  script: \r\n   - cd www.thetestcompany.de \r\n   - echo 'Deploy www.thetestcompany.de' \r\n  after_script: \r\n   - cd .. \r\n  environment: prod \r\n  needs: \r\n   - build-www.thecodecampus.de \r\n  dependencies: \r\n   - build-www.thecodecampus.de \r\n  only: \r\n   - master \r\n  when: manual \r\n\r\ndeploy-www.mail.thetestcompany.de: \r\n  extends: \r\n   - .runner_tags \r\n   - .ssh \r\n  stage: deploy \r\n  image: kroniak\/ssh-client \r\n  script: \r\n   - cd www.mail.thetestcompany.de \r\n   - echo 'Deploy www.mail.thetestcompany.de' \r\n  after_script: \r\n   - cd ..\r\n  environment: prod \r\n  needs: \r\n   - build-www.mail.thetestcompany.de \r\n  dependencies: \r\n   - build-www.mail.thetestcompany.de \r\n  only: \r\n   - master \r\n  when: manual<\/pre>\n
So now the jobs are configured and we are ready to run the Gitlab CI pipeline. The result will look like illustrated in the following picture. At first sight the major advantage of Gitlab CI, compared to Jenkins, jumps right into our eyes. It’s the smaller granularity of the job visualization. You see the status of every job you specified inside a stage. Therefore debugging is way more efficient. The granularity of this graph is completely up to you and how you define your jobs. Additionally Gitlab-CI offers functionalities to build up a directed acyclic graph<\/a>. This opens up the possibility to start jobs of a following stage, even if not all of the jobs in the current stage finished. This is a very big advantage, as this increases performance of the pipeline significantly.<\/p>\n
\"\"<\/a><\/h4>\n
 <\/p>\n
Jenkins vs Gitlab Conclusion<\/h3>\n
So now we know how each of the CI Tools can be configured. Lets have a look at the Pros and Cons of each one:<\/p>\n
\n
Gitlab Pros<\/h4>\n