quartz/content/out/notes/continuous-integration.md

title	draft
Continuous Integration	true

Continuous Integration

1 What is it

continuous --> is always happening integration --> connecting software components

inc ontrast to ad hoc, occasional integration:

• diverging component developmetnamy break integration
• repaiing software may be expensive

supports 'aglile' software dev

• like test driven development, help catch issues early

usually automated

2 Purposes

• checking code syntax
  • e.g., have CI compile the code and report errors
  • (local devs compilaer may be different from remote)
• checking semantics of code
• building docs
  • e.g., auto run javadoc
• running projects code tests
  • auto run JUnit, and report fails

3 Starting CI jobs

• from version control
  • e.g., every commit triggered CI jobs to run
  • starts on a push to server
• manually
• on a schedule

4 Runs asnychronously

• dont require devs to wait for completion
• common to run locally as well as on consistent standard environment

other timescales

• local checks as you commit
• checks as you type
• checks as you save

5 Output

since CI is asynchronous, its feedback is also

e.g.,

• web badges showing status
• can send emails
• messaging platform
  • e.g., slack, discord, teams
  • webhooks etc

git project websites usually provide logging interface, will watch scripts in virtual terminal and capture output from CI scripts

6 Github piplines

a pipeline has multiple stages

• e.g., test, build, deploy each stages has multiple jobs
• e.g., JUnit, custom tests, etc

7 Yaml

most Ci frameworks use YAML for their configuration structured text based formats

• python-like format or ≈JSON

8 configurationg from git repo

CI config often via file in git top-level directory

• CI is version managed

Gitlab pipeling specs go into .gitlab-ci.yaml:

• shows command sequece to run for a jon, within a stage
• output from commands is stored for a subsequent viewing
• indicates what files 'artifacts' should be kept from jobs