docs(daily-email): add 2022-11-17
This commit is contained in:
parent
32a41a245b
commit
2b0a5198b3
17
website/src/daily-emails/2022-11-17.md
Normal file
17
website/src/daily-emails/2022-11-17.md
Normal file
|
@ -0,0 +1,17 @@
|
||||||
|
---
|
||||||
|
title: >
|
||||||
|
Agnostic CI pipelines with run files
|
||||||
|
pubDate: 2022-11-17
|
||||||
|
permalink: >
|
||||||
|
archive/2022/11/17/agnostic-ci-pipelines-with-run-files
|
||||||
|
---
|
||||||
|
|
||||||
|
As I work on various projects, I use several different CI tools, such as GitHub Actions, Bitbucket Pipelines, and GitLab CI, as well as hosting providers that have build and deploy steps.
|
||||||
|
|
||||||
|
Some only run continuous integration checks, like automated tests and static analysis, some build and push Docker images, and some use Ansible and Ansistrano to deploy the changes to production.
|
||||||
|
|
||||||
|
Each tool has its configuration file with different settings and formats.
|
||||||
|
|
||||||
|
Rather than being too tightly coupled to a particular tool, I like to keep things as agnostic as possible and [use a run file]() with separate `ci:build` and `ci:deploy` tasks.
|
||||||
|
|
||||||
|
This means that all the logic is within the run file rather than the CI tool-specific configuration file, so the file is shorter and cleaner; I can make changes to the CI tasks locally and quickly test changes and iterate, and also, as the logic is within the run file, I can easily switch to a different CI tool if needed without making changes to the tasks themselves.
|
Loading…
Reference in a new issue