Shulou(Shulou.com)05/31 Report--

This article mainly explains "how to implement micro-service CD". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "how to achieve micro-service CD".

Microservices and CD

According to Martin Fowler, microservice architecture is "a way to design software as a set of services that can be deployed independently". This approach has become the mainstream of building distributed systems / applications; according to Jez Humble, CD (continuous delivery) is "the ability to safely and quickly put all types of changes-including new features, configurations, bug fixes, and experiments-into production in a sustainable manner".

Whether it's an integrated architecture or a micro-service architecture, regardless of the target deployment environment or our architecture choice, it's important to design the CD workflow so that any changes we make to the application can be put into production. CD workflow is the core of DevOps process, which can well connect various functions in the organization, including development, QA, IT operation and maintenance, and so on.

Four challenges of microservice architecture CD

Maintain the integrity of complex distributed systems: as we decompose large integrated systems into smaller, more manageable micro-services, the overall complexity of the system itself increases, and we begin to deal with problems related to distributed systems.

Release functionality safely and quickly: when our functionality may involve changes to one or more microservices, we need to consider how to manage frequent feature releases

Manage the deployment of different technology stacks: microservice environments usually include different technology stacks for services, and the management and deployment process across technology battles is challenging

Processes and tools for deploying services independently: there are many tools available for building CD workflows, but choosing tools and developing CD workflows is not an easy task.

Five thoughts on Micro-Service Architecture CD

Prepare the test strategy

Compared with the traditional integrated architecture applications, the testing and verification of micro-service architecture is more detailed and complex. An effective testing strategy must take into account both the need to test a single service and the need to verify the behavior of the entire system.

For pre-production testing of services, especially in isolation, traditional methods still apply. The test pyramid can still help us maintain a balance between different types of tests. However, the effectiveness of this testing approach is limited when testing service aggregation. We will encounter some types of errors that cannot be simulated in the test environment, such as problems caused by the final consistency in the distributed system, hardware and network failures that lead to partial failure of the system, and so on.

We'd better use some technologies to complement traditional testing, such as synthetic user testing, lightweight user acceptance testing, fault injection testing, and so on.

Check CI practice

CI is a key practice of CD. In addition to building servers and building definitions, backbone-based development and functional switching are two key practices for implementing a simple and powerful CI process.

In backbone-based development, developers collaborate in a branch called "trunk". The advantage of this is to avoid the drift of the development branch and the resulting merge hell. This is contrary to the practice of maintaining long-term characteristics and releasing branches. In the branch model, although we may run the build on each branch, in fact, we do not have continuous integration.

For backbone-based development, you need a control called feature toggles. Feature switching supports multiple submissions of a combination of WIP and completed functionality. With these switches, we can turn off the display of incomplete features in the production environment until these features are fully developed and tested in the production environment. Feature switching is usually stored in a specification or configuration file near the code base and turned on by an automated program in the CD pipeline in a specific environment.

Once we have a mechanism for maintaining feature toggles, we can use the same mechanism to introduce other types of toggles, such as release toggles (controlling access to unfinished code), Ops toggles (controlling the behavior of production code), permissions toggles (to turn on the specific behavior of privileged users), and experimental toggles (for multivariable testing-the degree of functionality received before making it permanent).

Plan the environment.

Environmental plans include our set of environments, their intended use, strategies for promoting artifacts through these environments, and toggle status in these environments.

First, consider what environments are needed and their expected use cases. Different departments in the organization have different competitive needs. When creating an environment, we should meet all these competing needs.

Second, if possible, consider using a cloud infrastructure to dynamically create an environment. For example, using the tagging feature of Kubernetes, you can create automated tests in a flight test environment, rather than in a long-standing environment.

Third, the CD pipeline generates a lot of artifacts, so how much artifacts should we consider to store? How much repositories we need and so on.

Manage the configuration well

The configuration of the application includes things that are different from each deployment and should be stored separately from the code. So what should we do with configuration when we have a set of microservices?

One way is to centrally manage the deployment configuration in repositories such as Consul or Vault, and expanding the deployment configuration in Chef and CD pipes will only make it more difficult to understand.

Another technique is to adopt a standardized process of distributing configurations, allowing services to handle the configuration according to the stack, regardless of the technical battle of the service. For example, we usually refer to 12-factors to avoid distributing configuration files.

Finally, key parts such as certificates need a governance process to ensure that they are properly managed. It's usually a manual process, but we need to think about it early and arrange it.

Be prepared for possible mistakes

In a micro-service system, multiple services are updated frequently. What do we do when the deployment of services introduces instability or bug?

Rolling back, finding the root cause of the failure and fixing it as soon as possible is the best response in most cases. A prerequisite for rollback is to ensure that we can release directly from the hotfix branch to production.

Rollback operations are often tricky in a production environment. In most cases, it is relatively easy to roll back if the change is small and you understand the cause of the problem. However, if the deployment contains changes that are not easy to understand, such as DB changes, especially those involving schemas, you need to separate the DB changes from the code changes in a continuous deployment to ensure that DB changes are backward compatible with earlier versions of the code.

Thank you for your reading, the above is the content of "how to achieve micro-service CD". After the study of this article, I believe you have a deeper understanding of how to achieve micro-service CD, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.