Click on the asynchronous book, the top public account

Every day to share with you IT good books technology dry goods workplace knowledge

This guide applies to:

You work in technology, as a product manager or an MBA. Your team plays A/B testing, features switch, and you have A dog in your office. Of course, you already understand what a feature branch is, what a 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 about what they’re building. But your customers still can’t get those features any faster. You still have to wait for the issuing train to leave the station. You’ve heard etsy,Flickr,Google and others deliver 100 times a day. How do they do it?

Your development team wants to implement “Continuous delivery”. You’ve heard some good things, but you’re also worried that changes are coming into the product without proper testing or proper marketing. So, what exactly is a CD?

I’m here to demystify these practices, show you how important they really are “on the business side” and get you involved. It’s not really complicated, we have diagrams and all the information.

Let’s start with some conceptual definitions and examples.

CI — Continuous Integration

In traditional software development, the integration process usually takes place at the end of the project, after everyone has finished their work. Integration often takes weeks or months and can be painful. Continuous integration is the practice of integrating early in the development cycle so that code can be built, tested, and consolidated more often.

CI means that a developer writing on a laptop at home (say, Steve) and another developer writing on a desk in the office (say, Annie) can write software for the same product and combine their changes in a single place called the source code repository. They can then build the software from the code they write and merge together, and test whether it works the way they expect it to.

Developers typically use tools called CI servers to build and integrate them. CI requires Steve and Annie to have self-testing code. The code tests itself to make sure it works as expected. These tests are often referred to as unit tests. After integrating the code, When all the unit tests pass, Steve and Annie get the green build. This indicates that they have verified that their changes are successfully integrated and that the code works as expected by the tests.

However, although the integrated code works successfully, it still cannot go into production because it has not been tested and verified to show that it works in a similar production environment.

You can read more about CI after completion in the “Continuous Delivery” section below.

In order to practice CI, Steve and Annie had to submit their code to the main source repository for intensive, frequent integration and testing of their code. Usually several times an hour, but at least once a day.

The advantage of CI is that the integration code becomes “non-event”. Software is written and integrated all the time. Prior to CI, code integration took place after the creation process, all at once, and then took an unknown amount of time. Now with CI, code integration happens every day in a matter of minutes. It’s just the way we work.

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

Continuous Delivery — CD

Let’s go back to the two developers, Steve and Annie. Continuous delivery means that every time Steve or Annie changes, integrates, and builds code, they also automate 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, the deployment pipeline has a development environment, a test environment, and a quasi-production environment, but these phases vary by team, product, and organization. For example, our Mingle team has a quasi-production environment called “Cake” and Etsy’s quasi-production environment is called “Princess”. (Docker technology system)

In each different environment, the code Annie or Steve wrote was tested separately. This gives them more and more confidence. For you, it’s code that works when it’s deployed to production. Crucially, code must pass the previous tests in the deployment pipeline before it can be promoted to the next test environment. In this way, Annie and Steve can get new feedback from each environment test. If something goes wrong, they can more easily understand what the problem is and fix it before the code goes into production.

Continuously Learning

This process is very helpful for our work. This means that if Annie’s tests pass in all environments, you know that her code should also work as expected in production. Once all environments are tested and approved, you can immediately decide if they are available to your users. 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 pretty darn!

Continuous Deployment

This is a practice where every change Steve and Annie make is automatically put into production after it passes all the testing stages. Tim Fitz first came up with a good explanation. Some companies do this, some don’t. To achieve continuous deployment, you first need to achieve continuous delivery. So it’s not important to decide which CD is right for you before you start practicing. Either way, I think continuous delivery is about things that help overall business capabilities, 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.”

DevOps (Development and Operations — Development and Operations)

The word “DevOps” comes from a combination of “development-development” and “operations-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 referred to as operations. Specifically, communication and collaboration in software delivery and deployment is aimed at delivering higher-quality software faster and more reliably.

Common characteristics of organizations with a so-called DevOps culture are autonomous multi-skill teams (Steve, Annie, and Joey are all on the same team), a high level of test and release automation (continuous delivery), and multi-skill team members with common goals.

One model you might find working within your organization is that our developers Steve and Annie will work with operations people like Joey to deliver finished software, instead of just “handing” their just-finished code to Joey to release. Similarly, Steve, Annie, and Joey will all be part of the public product or service team, and together they will be responsible for the support and maintenance of the product, rather than leaving the operations team solely responsible for the support.

You’ll also see automation of actions becoming increasingly important for organizations that implement CDS and DevOps. This is because in order to achieve the repeatable, regular, and successful software release processes that we expect from CDS and DevOps, organizations must move to automation. Manual processes are error-prone and inefficient.

DevOps cultures are often associated with continuous delivery, as 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 that 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 that practice CDS and embrace the DevOps culture will deliver more valuable, more reliable software to their customers, and more often. Isn’t that great, right? Especially if you are on the “business side” (more customer trust, more orders).

I’ll talk more about why you should care about these concepts next time. I’ll talk about its impact on your business and how to intervene. If you have any questions, please let me know in the comments. The point of this content is to inform and empower you about technical practices that are relevant to the business. Great question, welcome to ask!

Useful terminology

Checking in – Checking in

The process of pushing locally developed code changes to a common code repository. (Also called Commit)

CI Server – Continuous integration Server

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

Development environment – The Development environment

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

Deployment Pipeline – Deploy pipeline

This is a series of stages that Steve and Annie’s code goes through before it is finished and ready for delivery into production. Typically, these would be “Build, unit test, functional test, performance test, deploy.” Different automated tests will be run at different stages. Software can only be delivered to production if the code flows through the deployment pipeline.

Green Build – Green build

Green is a sign of success. A green release, or build, is a release of a specific phase of the development and delivery process through testing. Typically, a build or release will not be upgraded to the next phase of the deployment pipeline unless it is green. The opposite 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 is the process of building a small part of a product at a time until it is complete. A portion is added to each increment, which may be small or large. You can use CI with incremental development, but it can be difficult to achieve continuous delivery or continuous deployment with incremental development because you have to wait until all the increments are complete before delivering value. A good example of the difference between incremental and iterative development is Jeff Paton’s Mona Lisa. (See the illustration below.)

Integration – Integration

All code written by individuals or teams needs to be merged. We call this integration. In continuous integration, we usually mean that software code from individuals needs to be merged periodically. In continuous delivery, we usually refer to the integration of software from different teams to create the entire product.

Iterative development – Iterative development

Not to be confused with incremental development (see above). Iterative development is the process of building a product one step at a time, perfecting it until it is finished. Products are developed iteratively, meaning that the same parts are improved each iteration. Plan and anticipate changes to the product between features that differ from iteration to iteration. You can develop iteratively using continuous integration, continuous delivery, or continuous deployment. The difference between incremental and iterative development is shown in the figure above.

Master/ Trunk /mainline –

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

Production environment – The Production environment

This is where the software is deployed or distributed. Customers who use your product or website are most likely to use this environment. You can also call it: “in production,” “in production,” “online.”

Red Build – Red build

Red indicates failure. A red version, or build, is a version that has not passed a specific phase of testing during the development and delivery process. Generally, if the software is built in 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 repository

This is where the source code is. Steve and Annie have their own versions of native code that they are working on (meaning the code is on their own machines), but the source code base will contain all of the code after the developer submits the modified code.

Test Automation – Automated testing

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 code written tests that can be run automatically after the code is checked into the common source code base.

In the CI world, unit tests are run every time software is integrated and built. If the test does not pass, the software version is determined to not work, “red,” “broken.” When this happens, some workplaces will have a “red light” or sad sound (indicating that the build has 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 removing the previous change that caused the interruption.

Unit tests – Unit tests

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

mo4tech.com (Moment For Technology) is a global community with thousands techies from across the global hang out!Passionate technologists, be it gadget freaks, tech enthusiasts, coders, technopreneurs, or CIOs, you would find them all here.

Tell the product manager what continuous delivery and DevOps are

CI — Continuous Integration

Continuous Delivery — CD

Continuously Learning

Continuous Deployment

DevOps (Development and Operations — Development and Operations)

What’s next?

Useful terminology

Further reading

Tell the product manager what continuous delivery and DevOps are

CI — Continuous Integration

Continuous Delivery — CD

Continuously Learning

Continuous Deployment

DevOps (Development and Operations — Development and Operations)

What’s next?

Useful terminology

Further reading

Related Posts

Study Notes provides an in-depth understanding of JavaScript

JVM Learning Notes: The class loading process

What Python gadgets you didn’t know