Continuous integration
لم يُترجم بعد؛ يُعرض باللغة الإنجليزية
Continuous integration means everyone merges small changes into a shared main branch often, and a machine checks every one. Follow a commit from your laptop as each push starts an automated pipeline on a server: install, lint, test, build. Watch a failing test turn its lamp red and block the merge, see the fix go green, and learn how continuous delivery and deployment carry the same idea on to releasing.
5 أسئلة سريعة
اختر إجابة لتعرف السبب. تُحفَظ نتيجتك مع تقدّمك.
01What starts the CI pipeline in this lesson?
The push itself starts the pipeline. Every push is checked automatically, so nobody has to remember to run the checks.
02The commit's add() returns a - b. Which stage catches the mistake?
a - b is valid Python, so install and the linter are happy. Only a test that checks add(2, 3) == 5 notices that the answer is wrong.
03The test stage fails. What happens next?
The pipeline stops at the first failure, and a protected main branch only accepts changes whose required checks passed.
04Why does CI aim for fast feedback, such as a build of about ten minutes?
A quick red result means you fix the mistake while you still remember the change, before others build on top of it.
05What is the difference between continuous delivery and continuous deployment?
Both build on CI. Continuous delivery stops at ready-to-release with a button press; continuous deployment removes the button.
المسرد
- Commit
- A saved snapshot of your changes to the code, with a message saying what changed.
- Push
- Sending your commits from your computer to the shared repository.
- Continuous integration (CI)
- Everyone merges small changes into the shared main branch often, and an automated pipeline checks every push.
- Pipeline
- A list of automated stages, such as install, lint, test and build, that runs in order on a server for every push.
- Linter
- A tool that reads code without running it and flags likely mistakes, such as a name that is never defined.
- Required check
- A pipeline result that must pass before a change may merge into a protected branch.
- Continuous delivery
- Keeping every green build ready to release, so a person can release it at any time with one action.
- Continuous deployment
- Releasing every change that passes the pipeline to users automatically, with no button press.
الملاحظات والمصادر
- In a real pipeline the install stage also installs the tools the later stages use, for example pip install . pytest ruff build.
- Real pipelines often run some checks side by side to save time and add others, such as type checks or security scans. Install, lint, test, build is a common, simple shape.
- A linter checks code without running it, so it cannot tell that add should add: a - b is perfectly valid Python. Only a test catches that kind of mistake.
- Blocking the merge is a setting on the shared repository (on GitHub, a branch protection rule with required status checks), not something the pipeline does by itself.
- Martin Fowler gives a ten-minute guideline for the main commit build: slower pipelines lose the fast feedback that makes CI work.
- Martin Fowler, Continuous Integration
- Martin Fowler, Continuous Delivery (bliki)
- GitHub Docs: Continuous integration with GitHub Actions
- GitHub Docs: About protected branches (required status checks)
- GitLab Docs: Get started with GitLab CI/CD
- pytest: Get started
- Ruff: The Ruff linter
- pip install (pip documentation)
- build: a simple, correct Python packaging build frontend
- J. Humble and D. Farley, Continuous Delivery (Addison-Wesley, 2010)
اختبار يتاح بعد الخطوة الأخيرة.