What DevOps is
لم يُترجم بعد؛ يُعرض باللغة الإنجليزية
DevOps joins building software with running it. One team owns a single loop: plan, code, build, test, release, deploy, operate and monitor, then back to plan. Follow one small change round that loop, a one-line Python fix, as machines build, test and ship it. Then see how DORA's four key metrics measure how fast and how safely the loop runs.
5 أسئلة سريعة
اختر إجابة لتعرف السبب. تُحفَظ نتيجتك مع تقدّمك.
01What does DevOps join together?
Dev is development, building the software; Ops is operations, running it. In DevOps one team owns both halves of the loop.
02A developer commits a change. What does continuous integration (CI) do next?
A CI server notices every commit, builds it and runs the automated tests, the same way every time, with no one doing it by hand.
03Why does the test assert total([0.1, 0.2]) == 0.3 fail without round?
Floats are binary numbers that cannot hold 0.1 or 0.2 exactly, so the sum is a tiny bit off. The test catches it before users ever see it.
04What is infrastructure as code?
When servers are described in files, they can be reviewed, versioned and rebuilt exactly, just like application code.
05Which pair of DORA metrics measures stability?
Change failure rate (how often a deploy breaks something) and time to restore (how fast it is fixed) are about stability. Deployment frequency and lead time are about speed.
المسرد
- DevOps
- A way of working that joins building software (development) with running it (operations), so one team owns the whole loop and ships small changes often.
- Version control
- A shared history of every change to the code, such as Git. A commit is one saved change.
- Continuous integration (CI)
- Automatically building and testing every change as soon as it is committed.
- Continuous delivery (CD)
- Keeping every tested change ready to release at any moment. Continuous deployment goes further and releases every passing change automatically.
- Infrastructure as code
- Describing servers, networks and other infrastructure in code files, so tools can create identical copies every time.
- Monitoring
- Watching a live service with graphs and alerts. Google's SRE book names four golden signals: latency, traffic, errors and saturation.
- DORA metrics
- Four measures of software delivery from the DORA research programme: deployment frequency, lead time for changes, change failure rate and time to restore.
- Lead time for changes
- How long a change takes to go from committed to version control to running in production.
الملاحظات والمصادر
- DORA (DevOps Research and Assessment) now calls these change lead time, deployment frequency, change fail rate and failed deployment recovery time, and its current guide adds a fifth metric, deployment rework rate. The figure uses the four classic names.
- Python floats are binary (IEEE 754) numbers, which cannot hold 0.1 or 0.2 exactly; that is why sum([0.1, 0.2]) prints 0.30000000000000004. Real shops often store money as whole cents or use the decimal module.
- The eight-stage infinity loop is a common teaching picture, not a standard. Real teams name and split the stages differently, and many stages overlap or run at the same time.
- Continuous delivery keeps every change ready to release and a person may choose when; continuous deployment releases every passing change with no human step. Both are called CD.
- The code card is real Python 3. Run it and it prints nothing, because the assert passes; with the old line return sum(prices) it stops with an AssertionError.
- DORA: DORA's software delivery performance metrics
- DORA: Research programme
- DORA capabilities: Continuous integration
- DORA capabilities: Continuous delivery
- DORA capabilities: Working in small batches
- Google SRE book, ch. 6: Monitoring Distributed Systems (the four golden signals)
- Google SRE book, ch. 8: Release Engineering
- Martin Fowler: Continuous Integration
- Martin Fowler: Infrastructure as Code
- Python Tutorial: Floating-Point Arithmetic, Issues and Limitations
اختبار يتاح بعد الخطوة الأخيرة.