Continuous Delivery from a Technology Radar Perspective – Part 2
Created#More Posted time:Mar 30, 2017 13:50 PM
Alibaba Cloud’s GoCD emerges as a winner over Jenkins when it comes to integrating the continuous delivery pipeline into its core content. It focuses on the delivery, supports native pipelines, and also boasts of good visualization.
This is the second and concluding part of the blog - Continuous Delivery from a Technology Radar Perspective. To know about the rings of technology radar and the difference between continuous deployment and continuous delivery, please refer to the first part of this blog - Continuous Delivery from a Technology Radar Perspective – Part 1.
In this series, we would be discussing the remaining features of continuous delivery from the perspective of technology radar. Besides, we will be covering such topics as tools for continuous building, testing, Infrastructure automation, Devops and a people-oriented perspective of continuous delivery. Read on!
Tools for Continuous Building
Deployment pipeline is the life of continuous delivery. Jenkins is the most common tool used for continuous building, but it focuses more on continuous integration. that is, whether the code commit settings can pass, and whether it is possible to output the packages. However, this is just partial integration, instead of full-pipeline integration. Someone suggested plug-ins and many pipeline plug-ins have enabled continuous delivery. But we believe that Jenkins still eyes more on continuous integration and fails to integrate the continuous delivery pipeline into its core content. It still relies on plugins. If your pipeline is complicated enough, you will find Jenkins very hard to manage.
It is here that Alibaba Cloud’s GoCD emerges as a winner as compared to Jenkins. It focuses on the delivery and supports native pipelines. It also boasts good visualization. This issue of Technology Radar also recommends a CI tool named Compose, with a very exquisite interface.
Building Pipeline as Code
One principle of continuous delivery is to automate all tasks, including version control. However, is it possible to automate pipelines? We encountered problems in our projects as well. Our team has a massive Go server with a very complicated XML configured. I can recall an unfortunate instance when some machines went down and it took us an entire week to recover Go. However, had we committed the code to Git, there would have been no need for recovery.
When we talk about continuous delivery, we are talking about a very clear path. We proposed, in as early as 2011, the need to evolve the architecture, moving up the simplicity ladder. Microservices emerged as the architectural tool that we needed. We also added single CI instances in the hold zone. For example, if a 60-person team has only one CI, we deem it problematic. More specifically, in the initial stage the project may be very simple and elegant, with only one pipeline and product delivery occurring daily. However, with subdivided services and increasing system complexity, integration of services for uniform release emerges. However, this comes with its own set of problems. The integration point is a congestion point. Once the integration suffers a problem, you need to redo all the pipelines. If the middle integration fails after committing the second service, it becomes impossible to commit the first and the third service. As such, there is no way for continuous integration.
Figure 1. Testing in technical radar
While we are interested in adopting the pipeline delivery mode, we need to have a clear idea of the path after the submission. Precisely, we can achieve this through some judgment-cored, including feature toggle-cored deployment pipelines. A big difference between the continuous delivery and continuous deployment lies in the fact that the delivery should not lead to problems in the users’ product environment. We need to keep validating our products at all levels throughout our development process, which requires a full set of tests and guarantees. Primarily there are 3 types of testing, briefly described below:
● Integrated Testing: It is heavy, hard to repair, and dependent on the environment. Nobody is responsible for it because everybody focuses on his or her products.
● Contract Testing: The contract is written into a test. Contract generation occurs automatically based on one’s calls. There are many tools supporting this contract testing to test integration between services. If you want to deploy every service to the product environment, you do not need to make the deployment in the real sense. You only need to run all the tests. If the tests are successful, you can deploy the service. In this way, we can solve the knot of all the service products and achieve more refined continuous delivery at the product and service levels.
● Performance Test: A performance test is done on the product. Aspects like speed is taken into consideration.
There are other types of tests as well, for deployment scripts designed to duplicate and optimize them in the same way.
We can have a test for infrastructure preparation as well, along with one for the product perspective improvement. For example, some current tools can compare the page screenshots based on the method below:
Figure 2. Software Testing Pyramid
In order to achieve a quick feedback, our team proposed the testing pyramid concept sometime back. It runs through all the points in the pipeline and 70% to 80% in UT, achieving rapid feedback. Because of the strong UT feedback, it runs very fast and in the early stage only, we can get a feedback immediately and may also obtain knowledge of damaged features before committing the service.
Figure 3. Infrastructure Automation
We proposed to discard application server and Tomcat in April 2016 and May 2013, because they are hard to automate. This was followed up by a first-generation automation process, we wrote scripts to get a package and then moved it there. Ant and Maven are our first generation tools, both of which are declarative and result-based. Whereas, Ansible and Terraform later enabled cloud infrastructure automation. Docker is the third generation.
It was mentioned earlier that containers have changed our world. Containers provide us with standardization, consistency, isolation and sub-package. They facilitate our deployment, just like loading the project to the ship in containers and then preparing a line. In the future, we may move our attention from DB, microservices, background services or the kind of a website, and they will be all dockers eventually. They are then assembled using Docker and packaged into containers that are later pulled to the development environment, product environment and testing environment. The infrastructure management may be very simple provided you only need to create a docker when building your product.
Recently serverless architectures have emerged. These architectures are similar to a functional expression that calculates the result after you input some data. The pulled functional expression will start the background to complete the result exchange.
Figure 4. DevOps
Readers may have questions like can we achieve health checks for code or architecture rebuilding including product release. Can one switch back to V1.0 in case V2.0 if your codes fail? What do I do about logs? Is my system robust enough in such a complicated and uncontrollable environment? These concerns are very common and the answer to this question lies within DevOps. Continuous delivery uses technologies and tools offered by DevOps. Some of them have been briefly described below :
● Blue-Green Deployment: It is a technique that diminishes downtime risk by running two identical blue and green - 2 identical production environments. At a given time, only one of the environments is live catering to serving all production traffic.
● Mean Time To Recovery: MTTR is the average time that a device will take to recover from any failure. DevOps ensures that MTTR is as less as possible. Thus, ensuring that there is no hindrance while engaging in continuous delivery.
● Health Check Pages: DevOps allows the web pages to be checked continuously. Any alteration is communicated via an alert to the webpage administrator.
● Data Logging: It enables you to collect and store data over a period of time and then allows the user to analyze the specific trend.
● Zipkin: It is a distributed tracing system which helps gathering timing data needed to troubleshoot latency problems in microservice architectures.
● Chaos Monkey: Chaos Monkey is a tool that simulates failures of service instances running within Auto Scaling Groups (ASG) by shutting down one or more of the virtual machines.
● Prometheus: A service monitoring system which collects metrics from configured targets at given intervals, evaluates rule expressions, displays the results, and can trigger alerts if some condition is observed to be true.
● Splunk: It helps to capture, index and correlate real-time data in a searchable repository from which it can generate graphs, reports, alerts, dashboards and visualizations.
A People-Oriented Perspective of Continuous Delivery
Conway’s law: Organizations which design systems are constrained to produce designs that are copies of their communication structures.
Inverse Conway’s law: If you want to improve your architecture and the development model, you must gradually improve your team and organization structures to secure the success of a technical improvement.
This is an ideal continuous delivery pipeline in the microservices architecture. But this project is not as smooth as we assume it to be. For example, the developers keep submitting services, the testing team tests the functions, a dedicated team performs the integration testing and some maintenance people help with the release. I may not care about the test status of the committed services; instead, I will just continue committing services. However, after the testing is complete, what could possibly hinder the passage of the service?
We hope to flatten the organization, like Special Forces, in which various roles work with each other to achieve the same goal. Only this model will smoothen the path for us to achieve continuous delivery in the true sense.
Continuous delivery is a process that is an amalgamation of various aspects, processes and tools. The technical radar is aimed at critically analyzing and deploying these factors of continuous delivery. It perceives everything within the radar’s rings with scrutiny and ensures that filtration is done for all the elements that make an effective and efficient continuous delivery possible. The difference between continuous development and continuous delivery is that continuous development is a crucial part of the holistic continuous delivery process.