Continuous Integration wird längst in vielen Projekten praktiziert. Kein Wunder, steht für das Tooling doch in vielen Fällen ein Jenkins oder Travis zur Verfügung. Mit GitLab CI ist dies jedoch nicht mehr nötig. Schritt für Schritt wird in dieser Session eine Pipeline mit verschiedenen Test- und Analysetools aufgesetzt -- zur Integration in neue und bestehende Projekte.

1. 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

2. Das Problem

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

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

5. 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

6. Jenkins hat seine
Daseinsberechtigung.

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

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

9. 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

10. Immer diese
Theorie.
Ich will etwas
erleben.

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

12. ❏ 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"]

13. ❏ 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]

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

15. 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

16. ❏ 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
…

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

18. 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"]
…

19. 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]

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

21. 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"
}

22. 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"]

23. 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

24. 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

25. 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, …

26. 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

27. Habenwill!

28. 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

29. Bunt ist’s …!

30. 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

31. Einrichtung von CI-Schedules

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

33. Das war’s. Danke.