Build Pipelines
Continous Integration
Martin Reinhardt
Agenda
Basics
How to use Build Pipelines
Structuring Build Pipelines
Examples
Problems
Links
Basics about Continous Integration
- Using the IDE is not automating
- .. and is not automatically a repeatable build
- continous integration per build tool (ant,maven,gradle ...)
- testing is not only running Unit tests
- failures in tests lead to failed builds
- fix build after error occured, don't waste time ...
- reuse artificats
But how?
Using Build Pipelines
- Split long running tests up to several jobs
- get faster feedback and have smaller changes
- less to merge and/or to
- don't use every test in a build pipeline (performance, code coverage)
- it's all about speed!
- can be parametrized (different configurations, environments)
- can be used to trigger a new release candidate (continous delivery with promotion)
- can run in parallel (e.g. integration and webservice tests)
Seperation of the jobs
Basic model
- build
- deploy
- integration
- ui
But
- if build takes to long split it up (~5 minutes)
- don't overengineer single jobs
- better: parametrize build (SVN-branch, configuration, ...)
- use groups to manage user rights in jobs
Examples
- Static Build Pipeline
- don't overengineer single jobs
- better: parametrize build (SVN-branch, configuration, ...)
- use groups to manage user rights in jobs
- use of triggers
HLR Pos
Problems
- Not so easy to configure: CI-Team
- not the full change history visible
- failed single job in pipeline blocks the next job
- but: you can fix it
- or: customize the trigger