Click to follow asynchronous books , stick to the public number

Share with you every day the knowledge of IT good book technology dry goods workplace

This guide applies to:

You work in tech, as a product manager or as an MBA. Your team does A/B testing, feature switching, and you have a dog in your office. Of course, you already understand what feature branching is, what CD is, and what a DevOps culture looks like. right? Well, of course.

You're already on the agile path, and the engineering team now meets weekly with your product people to discuss stories and iterations. They collaborate well and feel better and better about what they're building. But your customers still can't get these features any faster. You still have to wait for the release train to leave the station. You've heard that companies like Esty, Flickr, Google, etc. can deliver 100 times a day. How do they do it?

Your development team wants to implement "CD" (Translator's Note: Continuous delivery). You've heard good things about it, but you're also worried that these changes are coming into production without proper testing or marketing of those changes. So, what exactly is a CD?

I'm here to demystify these practices, show you how important they really are "in business terms", and get you involved. It's not really that complicated, we have diagrams and all the information.

Let's start with some conceptual definitions and examples.

Continuous Integration (CI – Continuous Integration)

In traditional software development, the integration process usually takes place at the end of the project after everyone has completed their work. The integration process often takes weeks or months and can be quite painful. Continuous integration is the practice of integrating earlier in the development cycle so that building, testing, and integrating code can happen more often.

CI means that a developer writing code on a laptop at home (such as Steve) and another developer coding on a desk in an office (such as Annie) can separately write software for the same product, merging their changes in A place called a source code repository. They can then build software from the code they wrote and merged together and test that it works the way they expect.

Developers typically use a tool called a CI server to build and integrate for it. CI requires Steve and Annie to have self-testing code. These code tests themselves ensure that they work as expected. Usually these tests are called unit tests. After integrating the code, when all unit tests pass, Steve and Annie get a green build. This shows that they have verified that their changes have been integrated successfully and that the code is working as expected by the tests.

However, although the integrated code works successfully, it is still not production-ready because it has not been tested and verified in a production-like environment to show that it works.

You can read more about after completing CI in the "Continuous Delivery" section below.

Remove

Click here to add image caption

In order to practice CI, Steve and Annie must commit code to the main source code repository, and integrate and test their code intensively and frequently. Usually several times an hour, but at least once a day.

The beauty of CI is that integrating code becomes "non-event". Software is written and integrated all the time. Before CI, code integration happened after the creation process, all integrations were done at once, and the time it took was unknown. Now with CI, code integration happens every day and only takes a few minutes. It's just how we work.

Chances are your team is doing CI (or at least they believe they are). You can confirm by asking if they integrate the code every day. CI is the first practice required for continuous delivery. In fact, if you've ever checked in help text, documentation, or images, you've probably been integrating constantly.

Continuous Delivery (CD)

Let's go back to the two developers, Steve and Annie. Continuous delivery means that every time Steve or Annie make changes, integrations, and builds to the code, they also do automated code testing in a state very similar to the production environment. We call this series of "deploy-test" operations to different environments the deployment pipeline. Typically, a deployment pipeline has a development environment, a test environment, and a staging environment, but these phases vary by team, product, and organization. For example, our Mingle team has a staging environment called "Cake" and Etsy's staging environment is called "Princess". (Annotation: Eliminate the difference between the development environment and the production environment, refer to the Docker technology system)

Remove

Click here to add image caption

In each different environment, code written by Annie or Steve was tested separately. This gave them more and more confidence. For you, it's the code that works when it's deployed to production. Crucially, code cannot be promoted to the next test environment until it passes previous tests in the deployment pipeline. This way, Annie and Steve can get new feedback from testing each environment. If something goes wrong, they can more easily understand where the problem is and fix them before the code goes into production.

Continuously Learning

This process is very helpful in our work. This means that if Annie's tests pass in all environments, you know her code should work as expected in production as well. Once all environments are tested, then you can immediately decide whether your users can get it. Do we want this green build in production now? of course! And, as your developers finish building, new, well-tested, working software is immediately available to customers. Cool!

Continuous Deployment

It is a practice that every change made by Steve and Annie is automatically put into production after passing all the testing stages. Tim Fitz first offered a good explanation. Some companies do this, some don't. To achieve continuous deployment, you must first achieve continuous delivery. So it's not important to decide which is better for you before you start practicing CD. Either way, I think continuous delivery is about things that contribute to the capability of the entire business, so you should at least be involved in deciding whether to use continuous deployment. After all, if you're reading this, you're probably on the "business side."

Remove

Click here to add image caption

DevOps (Development and Operations – Development and Operations)

The term "DevOps" comes from the combination of words "Development" and "Operations". DevOps is a culture that fosters collaboration between developers (like Steve and Annie) and other technical professionals (like 5-star operations star Joey)—often called operations. Specifically, it is the communication and collaboration in the software delivery and deployment process, aiming to release higher-quality software faster and more reliably.

Organizations with a so-called DevOps culture have common characteristics: autonomous multi-skilled teams (Steve, Annie, Joey are all on the same team), high levels of test and release automation (continuous delivery) Skilled team members.

Remove

Click here to add image caption

One pattern you might find useful in your organization is that our developers, Steve and Annie, will work with ops like Joey to deliver finished software, rather than just handing over the code they've just finished. "Joey goes to post. Likewise, Steve, Annie, and Joey will all be part of a common product or service team, and together they will be responsible for product support and maintenance, rather than leaving the operations team alone with support responsibility.

You'll also see the automation of operations becoming increasingly important for organizations performing CD and DevOps. This is because, in order to achieve the repeatable, regular and successful software release process we expect from CD and DevOps, organizations must turn to automation. Manual processes are error-prone and inefficient.

Remove

Click here to add image caption

DevOps cultures are often associated with continuous delivery because they both aim to increase collaboration between developers and operations teams, and both use automated processes to build, test, and release software more quickly, frequently, and reliably. People love all these things we want.

What's next?

While development teams often see immediate benefits from process improvements, CI, CD, and DevOps have many benefits for the rest of us as well. In short, I believe that organizations practicing CD and embracing a DevOps culture will be able to deliver more valuable, more reliable software to their customers, and more often. Isn't that awesome, right? Especially if you're on the "commercial side" (more customers trust, more orders).

Next time I'll go on to discuss more why you should care about these concepts. I'll discuss how it affects your business and how to get involved. If you have any questions, please share with me in the comments. The point of these is to inform and empower you about technical practices relevant to your business. Great questions, questions are welcome!

useful term

Checking in – check in

The process of pushing locally developed code changes to a common code repository. (Annotation: Also known as Commit, submit)

CI Server – Continuous Integration Server

Tools for building and testing source code. The CI server tells developers if their latest code builds were successful and if they continue to pass tests.

Development environment – development environment

Where developers create, integrate, build, and test code.

Deployment pipeline – Deployment pipeline

This is the series of stages Steve and Annie's code goes through before it's complete and ready to be shipped to production. Typically these will be "build, unit test, functional test, performance test, deploy". Different automated tests will run at different stages. Software can only be delivered to production if the code runs through the entire deployment pipeline.

Green build – Green build

Green is a sign of success. A green release, or build, is a release that goes through a specific stage of the development and delivery process. In general, a build or release is not promoted to the next stage of the deployment pipeline unless it is green. The inverse of a green build is a red build (see below)

Incremental development – Incremental development

Not to be confused with iterative development (see below). Incremental development refers to building a small part of the product at a time until it's all done. A portion is added in each increment, which may be small or large. You can use CI with incremental development, but with incremental development it can be difficult to achieve continuous delivery or continuous deployment because you have to wait until all the increments are complete before delivering value. A good example explaining the difference between incremental and iterative development is Jeff Paton's Mona Lisa. (Annotation: See the description below, which means different ways to reach the goal)

Remove

incremental development

Remove

iterative development

Integration – integration

All code written by an individual or team needs to be merged. We call it integration. In continuous integration, we generally mean that software code from individuals needs to be merged on a regular basis. In continuous delivery, we generally refer to the integration of software from different teams to create an entire product.

Iterative development - iterative development

Not to be confused with incremental development (see above). Iterative development is building the product bit by bit, improving it until it's done. Products are developed iteratively, meaning the same parts are improved each iteration. Features vary between iterations, during which changes to the product are planned and anticipated. You can use continuous integration, continuous delivery, or continuous deployment for iterative development. The difference between incremental and iterative development is shown in the diagram above.

Master/trunk/mainline – (Annotation: The concept of branching in the source code management system, please refer to the Git code management system for details)

"Master/trunk/mainline" is the main branch of the source code repository, the mainline. Most people develop on trunk, which means they always integrate their changes into mainline. Others do branch-based development when individual developers have their own branches, or teams will have branches with different features.

Production environment – production environment

This is where software is deployed or released. Customers using your product or website are most likely to use this environment. Also called: "in production", "in production", "online".

Red build - red build

Red means failure. A red version, or build, is a version that fails testing at a specific stage in the development and delivery process. Typically, if the build of the software is red, it will not be promoted to the next stage of the deployment pipeline. The opposite of a red build is a green build.

Source repository – source code repository

This is where the source code resides. Steve and Annie have their own local version of the code they are working on (meaning the code is on their own machines), but after the developer commits the modified code, the source code repository will contain all the code.

Test automation - test automation

Continuous integration and continuous delivery require high-quality automated testing. Testing is a way of checking that software is working as expected. Automated tests are tests written in code that run automatically after the code is checked into the public source code repository.

In the CI world, unit tests are run every time software is integrated and built. If the test fails, that software version is determined not to work, "red", "broken". When this happens, some workplaces have a "red light" or a sad sound (indicating that the build failed).

If the build fails, Steve and Annie (whoever submitted the bad code) need to fix it, make it green, and make it work. They can fix it by modifying the code, or remove the previous breaking change.

Unit tests – unit tests

Unit testing is automated testing of code by testing low-level, monolithic pieces of code to ensure that they are available and work as expected. Unit testing is considered a prerequisite for implementing CI and CD. (Annotation: Unit testing is well supported in many languages and frameworks)

Talk to product managers about continuous delivery and DevOps

Continuous Integration (CI – Continuous Integration)

Continuous Delivery (CD)

Continuously Learning

Continuous Deployment

DevOps (Development and Operations – Development and Operations)

What's next?

useful term

Further reading

Guess you like