[_fourzerofour]

This is fantastic, having looked through Martin's blog before and found some gems that really leveled up my process on managing code.

As an aside - beyond the coming installments of this series, can anyone recommend sources for setting up CI locally, or for small teams? DDG is giving me pages on GitHub Actions, Atlassian, and DigitalOcean blogs, but these are all process or product specific.

[stevekemp]

Mostly the driver doesn't matter; for the CI stuff you basically want to carry out "actions" on "events". As a concrete example you might wish to run your test cases when a new pull-request is opened, or an existing one is updated.

The way that glue/integration works is going to be somewhat specific to the setup you're already using. That's why you'll find Github Actions being documented for Github, Jenkins for self-hosted repositories, etc.

Broadly speaking it doesn't matter which "thing" you use to drive your CI, the key is that it works reliably and that the stuff which is executed is inside your repository. That way:

* Developers can run it manually if they wish (e.g. "make test")

* The CI system can be swapped out in the future, if you need to.

As a concrete example once I migrated a company's repositories from bitbucket, using their pipelines, to (self-hosted) Github Enterprise. Because the pipeline just said "Run .git/tests.sh" porting the glue was trivial.

I even published a github action for those using github, so that you can launch your project-specific tests in a portable and simple fashion:

https://github.com/skx/github-action-tester

[noxToken]

CI will always be product specific unless you're going to create your own scripts for your pipeline. Even then, your script for executing tests, deploying, etc. will still be dependent on your stack.

Some general guidelines:

When a developer's branch is pushed publicly, compile it and run tests. It must pass before being allowed to merge into develop/master/${specific-branch}. Require that merges to those branches are only fast-forward merges.

The types of tests needed will be dependent on your application. Make sure they're all green before proceeding. If not, log the failing tests. Depending on your application, you may want to have certain testing metrics also fail the build. For example, require that at least 50% of new lines of code have test coverage and 60% of your overall source code have coverage.

Run any static analysis tools and linters. Configure which rules should trigger failures or warnings.

Run any other scripts that aren't related to code quality like minification or building binaries.

Deploy your application to the proper environment.

This is a bare-bones list. Your application may have many more steps, but this should get you started.

[PhilippGille]

Are you looking for advice for tools or for how to configure a pipeline?

The other answer mentions some pipeline steps (lint, test, compile etc), so I'll focus on tools.

The heavyweight champion for self hosted CI is still Jenkins I think. Pipeline config files are written with a scripting language (Groovy) instead of yaml, which gives you a lot of options for customization: https://jenkins.io/

But for a first CI setup for a small team it might be too much. I think Drone is lighter and simpler, while still being popular enough for having a community that creates many plugins: https://drone.io/