Continuous Delivery from a Technology Radar Perspective - Part 1
Created#More Posted time:Mar 29, 2017 9:53 AM
Figure 1: Technology Radar
Technology radar is an emerging technology trend that refers to the act of categorizing various technologies into four quadrants that act as a radar in real life. It is a way of observing market trends, gathering information in a consistent manner and take decisions based on those observations. A technology radar does not make predictions, but discerns certain things in advance based on information derived graphically from the platform, language, as well as framework.
Technology radar has four rings or phases: Every ring represents the content category, the action to be taken or that not to be taken. Below is a brief discussion of the different rings of the technology radar:
● Hold zone: The outermost ring is called the hold zone. Any content categorized in this zone or ring is to be put on hold. This technology might be quite new, or might even change the world. However, it may not be mature enough to be used or implemented. One should postpone using it as much as possible.
● Assess phase: The third ring is the assess phase, any content located in this phase may require it to be validated and evaluated through a thorough research on how it may impact the enterprise. Content spotted in this ring is often interesting and can have the caliber to revolutionize the future. Yet, its full potential and challenges may still be undiscovered.
● Trial phase: This phase depicts that the technology placed in this ring is worthwhile to be applied in our projects. However, considering that it may not be fully tested, one should run it in an environment in which the risks are within a controllable range.
● Adopt zone: Any technology placed in the innermost ring, is recommended to be used in the projects.
The mechanism of a technology radar is best utilized when, consideration is taken for every item’s location in the ring.
Continuous Deployment, Continuous Delivery and Continuous Integration
We proposed continuous deployment in January 2010 in a trial phase. In July 2011, we upgraded continuous deployment to continuous delivery and shifted it to the adopt zone. Meanwhile, we wrote a book titled “Continuous Deployment” that comprised of our study and findings.
Readers may have questions regarding the difference between continuous deployment and continuous delivery. Why did we change the name from continuous deployment to continuous delivery?
Usually people are of the view that continuous delivery means to continuously deploy products into the product environment or deliver apps to the customers. But that idea is wrong. Continuous deployment is a deployment process and not a delivery process. Continuous delivery on the other hand does not deliver products, but the value of products.
One should ensure that the value is useful, its quality guaranteed, and it corresponds to the need of the customer. It is a method of development to build a product. You need to ensure that you are capable of delivering it to the customer at any time, instead of delivering it all the time. If the customer needs the product right now, it is then made ready immediately; however, if the customer does not need it now, you can provide it anytime in the near future in a continuous manner. Such arrangement is called continuous delivery.
Most developers, including agile development personnel, now adopt an iteration approach. For example, improvement and completion of a portrait of Mona Lisa always occurs through iterations. In any agile approach, we can perform iterations before the continuous delivery to initiate the integration just before the distribution and then release the deliverable to the customer. However, adopting continuous delivery makes it look like a jog, the extreme limit of which is the fact that every commit may generate a final form of the product eventually released to the product partner. Our every action is capable of releasing a product to the product environment. We often confuse this with continuous delivery, instead of one-click deployment.
In March 2012, continuous delivery made a stride in its development that resulted in the production of a lot of related content in the technology radar. For example, if you want to perform quick deployment of databases, you only need to write an automation script and click a button to visualize deployment. It looks simple. However, you cannot guarantee that the deployment scheme is flawless for continuous delivery. The question that may arise here is - Is there a way of rapid regression, including monitoring the product environment? All these require the support of an entire eco-environment and a full system instead of just one set of fixed scripts.
Automated infrastructure: On close analysis, our team came to the conclusion that it is not advisable to have many annotations. Your code cannot, by itself, describe the function that it enables, therefore annotations are required to achieve this goal. This clearly indicates that the code is not clear enough. If you leave your post one day, and no one can maintain your infrastructure, it indicates your infrastructure is not good enough. We often say that a piece of code is like a document. You need to treat it as code or a container to precipitate it. This is what we call infrastructure automation.
For continuous delivery, three aspects are very crucial - practice, tool and people.
Continuous Delivery from a Technology Radar Perspective
Initially, continuous delivery was assumed to be just a process. It began with code committing, to automated building, moved towards setting it, deployment and finally delivering it to the customer. We often think that continuous delivery mainly tackles deployment problems. If we can automate the deployment of this product, our production environment can achieve continuous delivery. It can be rightly concluded that a well-performed continuous delivery begins from committing.
The first item discussed hereunder is the Feature Toggle that allows us to release our features to the production environment without any loss at any time.
Feature Toggles: We can create toggles to switch off some features and switch on others. We can embed this toggle in the code or create a table of the database. If you do not want the customer to see a feature, you can switch it off to achieve continuous delivery. In May 2013, our team proposed the experimental automated deployment of pipeline and continuous delivery as well as continuous development in the cloud environment. We claimed to separate the deployment from the release in April 2016. Some people may think of deployment as delivery, which is not in fact correct. I can make the deployment before completing the work, but I cannot release it. The feature is always in a non-released status before its Feature Toggle is switched on.
Figure 2.Feature Toggles
Feature Branching and Gitflow
Feature branching refers to pulling a branch first for every new feature. For our project, we put Feature Branching into the hold zone in October 2012. You should avoid using it and consider why you want to use it.
Figure 3. Feature Branching and Gitflow on Radar
Gitflow, a branching model for Git, was put into the hold zone in May 2015. If you visit the community now, you can see many Gitflow articles. We published an article about the harmful Gitflow that has since aroused a strong backlash.
Figure 4. Gitflow Organizational Development Model
Gitflow Organizational Model: It is an organizational development method. In a very simple project with only one master maintained, the trunk branch, every commit is a release. But not every commit can be released to the product environment. Therefore, you need a development branch by features, such as e-mail and report features and then restore them (merge) to the branch. If you discovered problems in V1.0, you could pull a hotfix branch. You can also have a release branch, so that you can work on V2.0 features while V1.0 is in release.
The problem of such a model is that every merge point is an integration process. If you miss any branch, it means you are avoiding continuous integration. The branch serves for isolation. Currently, I do not want to merge this feature and would want to take it up later during the final integration of this discussion. However, in doing so, we will only manage to connect the master branch to the pipeline for continuous integration and the resulting processes will not be able to achieve continuous delivery.
Figure 5. Trunk Based Development
What we want is this development model with the trunk branch as the basis.
The connection between the trunk and the pipeline offers continuous delivery. It has a direct check out to the local environment in development for direct committing after development. But you may face an issue, if you are working on V2.0 features, before you complete the work, numerous features remain incomplete. If you push it to the product environment directly, the half-done features will lead to usage problems even if the customer can upload files. Specifically, this is why you need Feature Toggles.
In this first series of 2 blogs, we began by discussing the 4 rings of technology radar, the difference between continuous deployment and continuous delivery along with their aspects and functional conditions. The second part of this blog will talk about.the tools for continuous building, testing, infrastructure automation, Devops and a people-oriented perspective of continuous delivery.