Article Directory
Outline
With the progress of development of the Internet and IT infrastructure, software development, one of the biggest changes is the frequency of deployment.
More and more attention to product teams earlier (and more frequently) will be officially released product deployment into the production environment. Several
release cycles months or years is becoming less and less - especially in those pure build and deliver software products and services
company or organization.
In today's IT software services industry, the use of architecture and micro-service architecture service-oriented approach, developers
can design modular code. This allows them to deploy and simultaneously writes the changes to the code of the entire project
different parts. Shorten the deployment cycle of the product benefits are obvious:
- New products get to market faster
- Customers in less time to get the value of products
- Customer feedback will be faster back to the product group, which means that the development team can quickly iterative product
and repair BUG - You can also enhance the combat effectiveness and happiness developer
However, this change also brings rapid deployment of new challenges for the operations team or DevOps team. For
more frequent deployment, deployed code or reliability of the site is more likely to negatively impact the customer experience. That
is why the development of strategies to deploy code to minimize the risk of the product and the customer is very important.
A. The current challenges facing software applications
Current applications are often distributed and cloud-based. They can flexibly scale to meet demand, and
almost all of the deployment and application high availability architecture, due to the highly available architecture, at the time of failure, it is more
likely to recover quickly.
To meet today's consumers and customers, these applications almost always have frequent updates deployment. For example, a
mobile application or a consumer web site may experience multiple changes within a month. Some even
several times a day deployed to the production environment.
More likely (module) of the entire number of development projects require moving parts means increased problems. With
the multiple development teams to make changes throughout the code base, when a problem occurs inevitably difficult to determine
the root cause of the problem.
Due to the changing needs of consumers and customers, the product (a version of) life cycle must be shortened as much as possible, in the frequency
process complex deployment and iteration, collaboration and operation and maintenance of the code involving multiple development teams release maintenance. This rapid
iteration and release process must not make any mistakes, mistakes will find it more difficult problem than the traditional deployment. This
time on the need to develop code for the continued deployment of integrated tools and continuous delivery, and consequent concept of CI / CD's.
To meet these challenges, application development teams and infrastructure teams should be designed for the use of its products and
deployment strategies. Here are just more common code deployment.
II. The more popular ways to deploy introduction
2.1 Big Bang deployment
Big BangDeployment is to deploy early release code used in the software industry the way, Big bang deployment requirements
project extensive product development and testing before release, "waterfall model" is usually released with the successive versions associated.
When deployed using this method, often require multiple departments coordinated, replace the original version of all or almost all of the code
module. The advantages of modern applications on the client side or server-side regular automatic updates. This makes the big bang party
method of modern software development team, it is rather slow, not agile.
Big Bang Deployment features:
- All the main code is packaged in a single deployment
- New software completely replace the existing software
- Deployment often results in long development and testing cycles
- High failure rate rollback
- The time it takes to deploy high, will involve multiple departments
Big bang is not suitable for modern application deployment, because the risk for critical business applications to the public or to
say that is not acceptable in these applications, downtime means a huge financial loss. Rollback generally expensive, consuming
the time of, or even impossible.
But the big bang method can be used for non-production system (eg, re-create the development environment) or suppliers of packaging solutions
program (such as a desktop application).
2.2 rolling release
Rolling release : scroll, phased or step deployment. Deploy better than the Big Bang, because the rolling release minimizes the
number of related risks, including but not easily roll back due to user downtime.
In the rolling deployment, the new version of the application will gradually replace the old version. The actual deployment process occurs over a period of time,
rather than a complete release. In the meantime, new and old versions will coexist without compromising functionality or user experience. This over-
process the rollback any new components are not compatible with older components becomes easier.
The following figure shows a rolling deployment: on each server in the cluster, the old version is displayed in blue, the new version is displayed in green
Upgrading an application (application of a plurality of components constituting) is an example of rolling deployment. If the original application is deployed in the container
, it can handle one container when upgrading applications. Each container has been modified so that the slave application vendor
to download the latest vessel image point. If an application compatibility issues, old mirrors can recreate container.
In this case, the old and new versions of the suite of applications to coexist until every application upgrade.
2.3 blue-green deployment
Blue, green and deployment : The deployment also ensures the use of stable production environment. Constantly use the old version of the code (do not affect the
case of a version of access), and in addition a new version of the deployment environment and then test, test user will cut through traffic
to the new version, which is characterized by non-disruptive operations, upgrades the risk is relatively small.
Configuring the deployment of two completely different sets of products production environment, it is currently running a production environment that receives all the
user traffic (shown in blue). Another is its clone, but is idle (green). Both use the same database
back-end and application configuration:
The new version of the application is deployed in a green environment, and tested its functionality and performance. Upon successful test results, the application
program to route traffic from blue to green. Green has become the new production environments and provide services.
If the problem becomes active in green, traffic can be routed back to blue.
In blue-green deployment, two systems use the same database or a backend persistence layer. Keep applications data synchronization is very important.
For write operations, you can use the blue primary database for read operations, you can use the green secondary database. Once enabled
a green environment, you can turn off or recycle old blue instance. You can deploy an updated version on the instance of the recovery and make
it become the next version of the new green environment.
Blue, green and deployment depends on the traffic routing. This can be achieved by updating the host's DNS cname. However, the longer the TTL value
will delay the changes. Alternatively, you can change the load balancer settings so changes take effect immediately.
Blue-green deployment scenarios apply:
1、不停止老版本，额外部署一套新版本，等测试发现新版本OK后，删除老版本。
2、蓝绿发布是一种用于升级与更新的发布策略，部署的最小维度是容器，而发布的最小维度
是应用。
3、蓝绿发布对于增量升级有比较好的支持，但是对于涉及数据表结构变更等等不可逆转的升级，
并不完全合适用蓝绿发布来实现，需要结合一些业务的逻辑以及数据迁移与回滚的策略才可以完
全满足需求。
Canary 2.4 release
Canary deployment similar to the deployment of blue-green, but it is more risk averse. Using the phased handover process from blue to green,
rather than a single step to switch from green to blue.
The use of canary deployments of new application code in a fraction of the infrastructure products. Once the application is signed
release name only a few users will be routed to the application. This will minimize any impact.
In the absence of error, the new version can be gradually extended to the rest of the old version.
The following illustration shows canary deployment process:
The main challenge canary deployment release is to design a number of users will be routed to the new application method. In addition, some applications
may always require the same group of users for testing, while other applications may require every different groups of users.
For different routes to a specific user service module, consider the following techniques:
- Before allowing access to external users, internal users will be exposed to new versions of some of canary deployment
- Source-based routing IP range
- Publish the application in a particular geographic area
- Using application logic to unlock new features to specific users and groups. When the application process other user requests, this logic will be deleted.
2.5 A / B test
A / B testing is also run two APP environment, but blue-green and deployment are two different things, A / B testing is a
way to test the functional performance of the application, such as availability, popularity, visibility and so on, blue-green deployment the aim
is to release a new version of the application security and stability, and to roll back, if necessary, that the deployment is a blue-green environmental official online environment,
and a / B testing two sets of formal online environment, provide business services.
III. Deployment Best Practices
In modern software teams deploy code process, you can follow many of the best practices to reduce deployment risks:
-
Use a deployment manifest (checklist). For example, a checklist might be "only in app service is stopped
before you can back up all databases" to prevent data corruption. -
Using continuous integration (CI) technology stack. CI will ensure that the code library branch code (branch) only after a series of dependency checking,
unit and integration testing, and successfully constructed, in order to merge with the main branch (master). If the operation path this series of
errors on, it will build fails and informs the application team. Therefore, CI means that every change to the software
should be in. Examples of CI tools include: CircleCI, Jenkins. -
Continuous delivery (CD) technology stack. CD with CI, the package code is ready to be deployed to one or more environmental.
-
Using standard operating environment (SOEs). SOE use to ensure the consistency of the environment.
-
Use build automation tools to build an automated environment. With these tools, usually just click a button to destroy
the entire project infrastructure technology stack and rebuilt from scratch. -
Configuration management tools using the target server, such as Puppet, Chef or Ansible application operating system automatically setting
set, or installing software patch application operation. -
Use like Slack channels of communication to build and automatically notify unsuccessful application failure.
-
Create a process to alert the team responsible for the failure at the time of deployment.
-
Due to the availability of automatic rollback or error rate problems could not be enabled through the deployment of health check.
Reference
Jason Skowronski : https://rollbar.com/blog/deployment-strategies/
Octopus Deploy : https://octopus.com/docs/deployment-patterns/canary-deployments
