DevOps related concepts

What’s DevOps

DevOps, like agile, has evolved to encompass many different disciplines, but most people will agree on a few things: DevOps is a software development practice or a software development lifecycle (SDLC) and its central tenet is cultural change, where developers and non-developers all breathe in an environment where formerly manual things are automated; everyone does what they are best at; the number of deployments per period increases; throughput increases; and flexibility improves.

DevOps is a set of ideas and recommended practices around how to make it easier for development and operational teams to work together on developing and releasing software

What’s fundamental differences between Agile & DevOps

DevOps Lifecycle

Here is a brief information about the Continuous DevOps life-cycle:

1. Development

   In this DevOps stage the development of software takes place constantly. In this phase, the entire development process is separated into small development cycles. This benefits DevOps team to speed up software development and delivery process.

2. Testing

   QA team use tools like Selenium to identify and fix bugs in the new piece of code.

3. Integration

   In this stage, new functionality is integrated with the prevailing code, and testing takes place. Continuous development is only possible due to continuous integration and testing.

4. Deployment

   In this phase, the deployment process takes place continuously. It is performed in such a manner that any changes made any time in the code, should not affect the functioning of high traffic website.

5. Monitoring

   In this phase, operation team will take care of the inappropriate system behavior or bugs which are found in production.

DevOps Work Flow

What’s Jenkins

Imagine it as some sort of a magical universal remote control(神奇的通用遥控器) that can talk to many many different services and tools and orchestrate(编排) them. On its own, a CI/CD tool like Jenkins is useless, but it becomes more powerful as it plugs into different tools and services.

Jenkins itself is not a pipeline. Just creating a new Jenkins job does not construct a pipeline.Think about Jenkins like a remote control—it’s the place you click a button. What happens when you do click a button depends on what the remote is built to control. Jenkins offers a way for other application APIs, software libraries, build tools, etc. to plug into Jenkins, and it executes and automates the tasks. On its own, Jenkins does not perform any functionality but gets more and more powerful as other tools are plugged into it.

What’s containers

The short explanation is that a VM needs the huge footprint of an operating system, which overwhelms the application size, while a container just needs a few libraries and configurations to run the application. There are clearly still important uses for a VM, but a container is a lightweight solution for hosting an application, including an application server.

What’s Jenkins

A pipeline is a separate concept that refers to the groups of events or jobs that are connected together in a sequence:

A pipeline is a sequence of events or jobs that can be executed.

Here, you should see two familiar concepts: Stage and Step.

Stage: A block that contains a series of steps. A stage block can be named anything; it is used to visualize the pipeline process.
Step: A task that says what to do. Steps are defined inside a stage block.

What’s Dockerfile

A Dockerfile is a text document that contains all the commands a user could call on the command line to assemble an image.

What’s Kubernetes

To build complex applications requiring different components spanning multiple containers on multiple machines, you need tools to manage and orchestrate your containers. One tool that is helping to solve the orchestration needs of containerized applications is Kubernetes.

Kubernetes, in short, is an open source system for managing clusters of containers. To do this, it provides tools for deploying applications, scaling those application as needed, managing changes to existing containerized applications, and helps you optimize the use of the underlying hardware beneath your containers. Kubernetes is designed to be extensible and fault-tolerant by allowing application components to restart and move across systems as needed.

Kubernetes is itself not a Platform as a Service (PaaS) tool, but it serves as more of a basic framework, allowing users to choose the types of application frameworks, languages, monitoring and logging tools, and other tools of their choice. In this way, Kubernetes can be used as the basis for a complete PaaS to run on top of;

What’s CI/CD

The CI/CD tool can automate the tasks of checking in and checking out source code and collaborating across members

An assembly line in a factory produces consumer goods from raw materials in a fast, automated, reproducible manner. Similarly, a software delivery pipeline produces releases from source code in a fast, automated, and reproducible manner. The overall design for how this is done is called “continuous delivery.” The process that kicks off the assembly line is referred to as “continuous integration.” The process that ensures quality is called “continuous testing” and the process that makes the end product available to users is called “continuous deployment.” And the overall efficiency experts that make everything run smoothly and simply for everyone are known as “DevOps” practitioners

CI/CD doesn’t mean “always running.” It does mean “always ready to run.”

What’s CI

Continuous integration (CI) is the process of automatically detecting, pulling, building, and (in most cases) doing unit testing as source code is changed for a product.

The goal of CI is to quickly make sure a new change from a developer is “good” and suitable for further use in the code base.

Continuous integration detect changes always by Jenkins.

Why do we need Continuous Integration?

CI improves the quality of software, and reduces the time taken to deliver it, by replacing the traditional practice of testing after completing all development.

What’s CD

Continuous delivery (CD) generally refers to the overall chain of processes (pipeline) that automatically gets source code changes and runs them through build, test, packaging, and related operations to produce a deployable release, largely without any human intervention.

The goals of CD in producing software releases are automation, efficiency, reliability, reproducibility, and verification of quality (through continuous testing).

CD incorporates CI (automatically detecting source code changes, executing build processes for the changes, and running unit tests to validate), continuous testing (running various kinds of tests on the code to gain successive levels of confidence in the quality of the code), and (optionally) continuous deployment (making releases from the pipeline automatically available to users)

What’s artifacts

The objects created in the pipeline processing from the source code can generally be called artifacts.

Artifacts should have versions applied to them when they are built. The recommended strategy for assigning version numbers to artifacts is called semantic versioning(语义版本). (This also applies to versions of dependent artifacts that are brought in from external sources.)

Semantic version numbers have three parts: major, minor, and patch(主版本号,次版本号,补丁). (For example, 1.4.3 reflects major version 1, minor version 4, and patch version 3.)

The major version is incremented only for incompatible API changes. The minor version is incremented when functionality is added in a backward-compatible manner. And the patch version is incremented when backward-compatible bug fixes are made

Versioned artifacts built from source can be stored via applications that manage “artifact repositories.” Artifact repositories are like source management for built artifacts. The application (such as Artifactory or Nexus) can accept versioned artifacts, store and track them, and provide ways for them to be retrieved.

What’s Continuous Deployment(also called CD)

Continuous deployment (CD) refers to the idea of being able to automatically take a release of code that has come out of the CD pipeline and make it available for end users

An important point here is that just because continuous deployment can be done doesn’t mean that every set of deliverables coming out of a pipeline is always deployed. It does mean that, via the pipeline, every set of deliverables is proven to be “deployable.” This is accomplished in large part by the successive levels of continuous testing (see the section on Continuous Testing in this article).