Continuous integration and DevOps

Actually, this is an article about automation. Continuous integration, continuous delivery, continuous deployment, and DevOps are all about automation.

What is continuous integration?

Continuous Integration (CI). Just keep submitting code. Submit your own code and integrate it into the team’s code.

The benefits of continuous integration are: 1) Quick problem discovery Every update is integrated into the trunk, so problems can be found quickly and errors can be located easily. In team development, it is also easier to see the collective effort, reflecting the latest progress of the project.

Often, continuous integration mechanisms are complemented by automated testing. However, in my opinion, even without this mechanism, it is possible to detect problems early by simply running the project manually.

2) To prevent branches from deviating greatly from the trunk, resulting in integration difficulties or even failure. It might be more appropriate to refer to the trunk as the master library. This is something I’ve probably felt the most about using GIT. As anyone who has done development knows, if multiple people are working together, if you haven’t committed or gotten code for a long time, the chances of code conflicts are greater when it comes time to integrate.

Continuous integration is a software development practice where each member typically integrates at least once a day.

Continuous integration, continuous delivery and continuous deployment

3. Operating environment at different stages

Development and production environments go without saying, and there are many environments in between. These environments range in complexity between development and production environments.

1) QA environment As the name suggests this is the environment where functional testing is done, mostly manually, and not necessarily by QA alone. This environment usually bears some resemblance to the production environment, with some real third-party applications deployed. Sometimes it also doubles as a showcase environment or is a separate presentation environment.

2) Staging environment Pre-release environment. Very similar to the production environment, can be understood as a clone of the production environment. Same server system, configuration, network environment, topology, and application deployment method. QA can only be deployed to the production line after final verification of a new release at the staging Server.

Staging, or staging, in this case, continuous delivery.

In fact, for an application system, development is normal, deployment problems, the most common reason is different database, the other seems to be quite virtual. I wonder what database is used for this so-called Staging environment? It is ideal to use the database directly from the production environment, but it can be difficult if there are a lot of additions, deletions and updates.

3) E2E test environment what is this E2E test? End to End testing means testing from the user’s point of view to see if the user’s requirements are met. I think it’s confirmation/acceptance testing. What if the program is a black box? Isn’t that a black box test? Functional tests are black box tests. Unit testing is white box testing.

This stupid thing says something really weird:



So why is the E2E test environment intermediate between a staging environment and a production environment? Do you mean deploy to one of the customer’s machines for confirmation before you actually deploy? Don’t understand. In terms of hierarchy, this E2E test environment looks like a legendary pre-release environment.

Continuity and agility

Fifth, the conversation

According to the definition of Baidu Encyclopedia, it is as follows:

**DevOps (a combination of Development and Operations) ** is a collective term for a set of processes, methods, and systems used to facilitate communication, collaboration, and integration between Development (application/software engineering), technical Operations, and quality assurance (QA) departments.

IT is a culture, movement, or practice that values communication and collaboration between software developers (Dev) and IT operations technicians (Ops). Build, test, and release software faster, more frequently, and more reliably by automating the software delivery and architecture change processes.

It comes as the software industry increasingly recognizes that development and operations must work closely together in order to deliver software products and services on time.

In other words, DevOps is about development and operations working closely together. Dev is developers, Ops is operations.

However, we all know to work closely together, the question is how? Can’t, just oral say, emphasize the importance of solidarity is naturally close cooperation, isn’t it? What really matters is how to get this DevOps off the ground.

Again, the answer is automation.

Development tests can be automated, and the delivered program can be deployed automatically.

According to the past, the deployment of a system is not very complex, chi Chi development, testing, according to the deployment of manual instructions on the line. However, the scale of the system is getting bigger and bigger, and the architecture is changing from single to micro service. Each service is independently developed, deployed and configured, and the technology stack and system environment involved may be different, making the deployment work more and more complicated. At this time, if you still rely on manual deployment, step by step, heavy workload, and prone to error.

Here’s how it works now:

Deployment of some machines, specifically used to manage the code, online work, by the operation and maintenance of the online rules have been defined, as long as the development in accordance with the rules to visit this server for their own code synthesis and release, and finally their own online. Something that can be done automatically in code should never be done manually, which is on every developer’s mind.

Operations needs to be done, slowly precipitation in each platform, such as monitoring, have special monitoring component and visualization, basic services such as server, CDN, load balancing and other basic services can be outsourced to the cloud service vendors, journal also have special tools, link tracking also have special components and visualization, and gateway, etc., gradually, As long as these are configured, developers can also do some of the work of operation and maintenance. After all, developers are the ones who know the code best. If there is a problem, they can look at the monitoring logs and locate the problem the fastest. Integration of development operation and maintenance.

DevOps is the hottest method and technology out there right now. The goal is to deploy changes quickly and safely to the production environment or users in a sustainable way, enabling continuous software delivery with shorter lead times, higher quality, and lower costs.

As you can see from the chart below, the overlap between development, test, and operations is DevOps, which means development, test, and operations are all DevOps. There is a methodology for agile development called Scrum that has a best practice (?) It’s a multi-functional team, which means that the people in the team, the roles are not very obvious, each person can do a lot of work. Same thing with DevOps here.

Six, summarized