Erste Schritte bei der
Einführung von CI-Pipelines in
GitLab-Projekten
Christian Mücke (Detlev Louis GmbH)
PHP User Group Hamburg, 20. März 2018

Das Problem

“Kannst du das schnell für
mich machen?”
Ja, aber … ach na gut.

Die Lösung
cp ../project/.gitlab-ci.yml .
… ?

Noch 28 Minuten …
1. Jenkins ist doch auch gut?!
2. Erinnerung: Warum Continuous Integration?
3. Toolset: Klassifikation und Web-Ressourcen
4. Schritt für Schritt zur CI-Pipeline

Jenkins hat seine
Daseinsberechtigung.

Continuous
Integration
Warum?
❏ Fehlervermeidung
❏ Vereinfachte Koordination
❏ Schnellere Releases

CI-Tools
❏ Korrektheit
❏ Codeanalyse
❏ Kompatibilitätsprüfung
❏ Sicherheit (CVEs)
❏ Compliance
❏ DokumentationEinsatzklassifikation

CI-Tools
Web-Ressourcen
❏ https://blog.jetbrains.com/
phpstorm/category/
php-annotated-monthly/
❏ https://github.com/
leanphp/common-dev
❏ https://github.com/
ziadoz/awesome-php
❏ https://packagist.org/explore/
popular
❏ PHP Magazin

Immer diese
Theorie.
Ich will etwas
erleben.

Stufenmodell: Build
Build
z. B. Composer-Libs,
Autoloading, Orchestrierung,
Assets kompilieren,
minifizieren
Test
Docs

❏ 1:n-Relation der
Stage zu Jobs
❏ Separate Jobs für
Prod und Dev
Die erste Stage.
stages:
- build
composer-dev:
stage: build
script: ["./composer.phar install"]

❏ Tags: Flexible
Auswahl von
Runnern
❏ Ausführung
einschränken
(wenn möglich)
Die erste Stage.
stages:
- build
composer-dev:
stage: build
script: ["./composer.phar install"]
tags:
- ci-internet
- docker-test
only: [branches]

Jedes Mal
Composer-Abhängig-
keiten laden. Ist das
nicht ineffizient? ⌛

Caching.
❏ Netzwerktraffic und
Ressourcennutzung optimieren
❏ pro Projekt, Branch, Job, …
❏ kann global und lokal pro Job
definiert werden
❏ Cache wird mit Start eines
Jobs geladen und nach
Ausführung gespeichert
Kenn ich!!1

❏ Beliebige Keys
möglich
❏ docs.gitlab.com
/ce/ci/variables/
❏ Literale
❏ Transienter Ansatz:
“Hit or miss - I don’t
care”
Caching
composer-dev:
stage: build
script: ["./composer.phar install"]
cache:
key: "$CI_JOB_NAME"
paths: ["vendor"]
untracked: true
…

Artefakte.
❏ Ansatz: “Brauche ich!!”
❏ dienen der Weitergabe oder
Archivierung von Ressourcen
❏ eignen sich bereits für einfache
Deployments
Hm?

Artefakte
❏ können per UI als
zip-Datei
gedownloadet
werden
❏ Jobs können
Artefakte verwenden
composer-dev:
stage: build
script: ["./composer.phar install"]
…
artifacts:
name: "composer-dev-
${CI_COMMIT_SHA}"
untracked: true
expire_in: 1 hour
paths: ["vendor"]
…

Das Ergebnis
❏ Alle Jobs einer Stage
werden parallel
ausgeführt
❏ Nächste Stage erst
bei Erfolg aller Jobs
❏ Fail fast => ggf. auf
mehrere Stages
aufteilen
stages:
- build
composer-dev:
stage: build
script: ["./composer.phar install"]
cache:
key: "$CI_JOB_NAME"
paths: ["vendor"]
untracked: true
artifacts:
name: "composer-dev-${CI_COMMIT_SHA}"
untracked: true
expire_in: 1 hour
paths: ["vendor"]
tags:
- ci-internet
- docker-test
only: [branches]

Stufenmodell: Test
Build
z. B. Composer-Libs,
Autoloading, Orchestrierung,
Assets kompilieren,
minifizieren
Test
PHPUnit / Atoum, Behat, PHPStan,
Code Sniffer, Mess Detector, …
Docs

Exkurs:
Composer-Scripts
❏ Ant? Phing? …
❏ Aufruf: composer run <job>
❏ Default-Timeout: 5 Minuten
❏ Gruppen von Jobs möglich
❏ Abbruch, wenn erster Job
einer Gruppe fehlschlägt
"scripts": {
"serve": "php -S 0.0.0.0:8080
-t public
public/index.php",
"check": [
"@test"
],
"test": "phpunit --colors=always"
}

Unser zweiter Job
<3
❏ Argumente an
CI-Ausführung
anpassen (z. B.
testdox-Format)
stages:
- build
- test
…
phpunit:
script: ["./composer.phar
run test -- --testdox"]
stage: test
dependencies: ["composer-dev"]
tags: ["docker-test"]

DRY
❏
…
.test_job_template: &test_job
stage: test
dependencies: ["composer-dev"]
tags: ["docker-test"]
phpunit:
script: ["./composer.phar
run test -- --testdox"]
<<: *test_job
lint:
script: ["./composer.phar
run lint --
--no-progress"]
<<: *test_job
http://knowyourmeme.com/memes/feels-good

Ein paar Tools zum Einbauen
❏ phpunit/phpunit
❏ jakub-onderka/
php-parallel-lint
❏ jakub-onderka/
php-console-highlighter
❏ squizlabs/php_codesniffer
❏ mayflower/mo4-coding-standard
❏ phpmd/phpmd
❏ phpstan/phpstan
❏ hmlb/phpunit-vw

Stufenmodell: Docs
Build
z. B. Composer-Libs,
Autoloading, Orchestrierung,
Assets kompilieren,
minifizieren
Test
PHPUnit / Atoum, Behat, PHPStan,
Code Sniffer, Mess Detector, …
Docs
Sami, phpmetrics,
Coverage-Infos, …

The same
procedure every …
yeah.
❏ Sonderfall:
Testabdeckung
bestimmen
❏ docs.gitlab.com
/ee/user/project
/pipelines
/settings.html#test-c
overage-parsing
stages:
…
- docs
…
.docs_job_template: &docs_job
stage: docs
dependencies: ["composer-dev"]
tags: ["docker-test"]
coverage:
script: ["./composer.phar
run test-coverage"]
coverage: '/^s*Lines:s*d+.d+%/'
<<: *docs_job

Habenwill!

GitLab Pages
❏ Statische Seiten
deployen
❏ Spezielle Job-Syntax
pages:
script: ["./composer.phar
run phpmetrics
&& mv public app_public
&& mv doc public"]
artifacts:
paths: [public]
expire_in: 30 days
<<: *docs_job

Bunt ist’s …!

Der Gerät schläft
nicht!
❏ GitLab Schedules
erlaubt periodische
Ausführung von Jobs
❏ z. B. für nächtliche
Selenium-Tests,
VM-Builds,
Langzeit-Load-Tests,
…
pdepend:
script: ["./composer.phar
run pdepend"]
only: [schedules]
<<: *docs_job

Einrichtung von CI-Schedules

Docs-Tooling
❏ phploc/phploc
❏ phpmetrics/phpmetrics
❏ sami/sami
❏ pdepend/pdepend
❏ sebastian/pdepend-process

Das war’s. Danke.