GitLab CI — CI/CD direkt im Repository integriert

Jenkins ist mächtig, aber für kleinere Projekte ist es mit Kanonen auf Spatzen geschossen. GitLab CI ist Teil von GitLab — eine CI/CD-Pipeline, definiert in .gitlab-ci.yml direkt im Repository. Kein externer Server, keine Jenkins-Administration.

.gitlab-ci.yml¶

stages:
  - build
  - test
  - deploy

build:
  stage: build
  image: maven:3.3-jdk-8
  script:
    - mvn compile
  artifacts:
    paths:
      - target/

test:
  stage: test
  image: maven:3.3-jdk-8
  script:
    - mvn test
  artifacts:
    reports:
      junit: target/surefire-reports/*.xml

deploy_staging:
  stage: deploy
  script:
    - ./deploy.sh staging
  only:
    - develop
  environment:
    name: staging

GitLab Runners¶

Ein Runner ist ein Agent, der Jobs ausführt. Shared Runners (GitLab.com stellt sie kostenlos bereit) oder eigene Runner. Docker Executor — jeder Job in einem sauberen Container. Die Registrierung eines Runners benötigt einen einzigen Befehl.

GitLab CI vs. Jenkins¶

GitLab CI: Einfachheit, Integration mit GitLab (Merge Requests, Environments), kein Wartungsaufwand für gehostetes GitLab. Jenkins: Flexibler, mehr Plugins, besser für komplexe Enterprise-Pipelines. Beide haben ihren Platz — GitLab CI für kleinere Projekte, Jenkins für große Enterprise-Setups.

CI/CD für jedes Projekt¶

GitLab CI senkt die Hürde für CI/CD. Jedes Projekt sollte einen automatischen Build und Tests haben — GitLab CI macht das trivial.