wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
# CI/CD
Continuous Integration / Continuous Delivery/Deployment

* Faster Software Development Lifecycle (SDLC)

A faster way for codebase changes to get propelled across to a codeforge, and later into production environments.
CI/CD is all about making new code get where it needs to be faster. (Lead time for changes) and deployment frequency (how often you commit code)

CI/CD automates merging, building and testing software so development happens quicker

Instead of having a "merge day" where all commits are inspected and manually merged to a main branch, CI/CD automates this

# CI
Let's say you make some changes to a program. Those changes usually have to be synchronized with some infrastructure, such as GitHub, so you make a commit or a pull request (depends on what access you have to the repo)
After you make that commit or PR, the CI/CD part of the infrastructure automatically checks your code against some rules the repo may have (style, quality, etc), builds the code by compiling it or doing any other steps so it can be tested
The unit tests (functional tests) are run automatically by the infrastructure and it reports back how many checks passed, errors, etc.
If every test passes, that version of the program is said to be okay, and then the CD part comes in

# CD
If Continuous Delivery is setup, the changes (that again pass all the tests and were automatically checked) need to be approved by a human to be merged into a production environment (so the changes are actually made for other people)
If Continuous Deployemnt is setup, the changes are directly deployed to a production environment (real world usage) without any human intervention. It's faster, but it may also be riskier. Maybe tests are wrong, the changes are malicious, etc...


An (bad) example of a CI/CD system is GitHub Actions (automated builds, tests, packaging with GitHub Packages)
wiki

User Tools

Site Tools

Page Tools
