1. Code on-line scheme

1. Deploy code manually early

  • Pure manual Scp, Rsync upload code.

  • Log in manually, Git pull or Svn update.

  • Manual XFTP, FTP, and Filezilla upload codes.

  • Development send compression package, RZ upload, unzip deployment code.

Disadvantages:

  • Full operation and maintenance participation, take a lot of time.

  • If there are many nodes, the online speed is slow.

  • Human errors abound and catalogue management is chaotic.

  • The rollback is not timely or difficult to roll back.

Schematic diagram of on-line scheme:

2. Rationalized online plan

Developers (RD) need to build LAMP environment on personal computer to test the developed website code, and pass the test in the office or IDC room test environment, preferably with full-time testers (TS).

Program code online to set the time, for example: three days line once, such as the site needs to update often can be online at 20 PM every day, this depends on the nature of the site business, the principle is to affect the user experience minimum.

The code needs to be backed up before going online. If the website program has a problem, it is convenient to go back. In addition, from the online skills, when uploading the code, it should be transmitted to the temporary directory of the server website as far as possible. If strictly updated, smooth the application server offline from the cluster node and then update.

As far as possible by the operation and maintenance personnel management online, for the functionality of the code, developers care more, and for the performance optimization of the code and the stability of the server after the online, operation and maintenance care more about the stability of the server, therefore, if the website downtime problem belongs to the operation and maintenance, it is necessary to let the operation and maintenance online, so that it is more standardized and scientific. Otherwise, the development will be updated at will, and the operation and maintenance will be responsible for the problems, which will be wrong, and the operation and maintenance will never be able to raise its head.

Web code standardization on-line flow chart

3. System and process of launching large enterprises

When a JAVA code environment goes live, several machines need to be updated simultaneously or in batches

Local developers fetch the SVN code. The same day online submission to trunk, otherwise, long term project single branch development, then in merge mainline (Trunk)

During the development and test of office Intranet, the developer or configuration administrator realizes unified deployment through Jenkins deployment platform (that is, the deployment platform controls the development machine to fetch the code from SVN, compile, package and publish it to the development machine, with package name such as IDc_dep.war).

The developer notifies or tests the program with the tester, and when there is no problem, the configuration manager tags it with a new tag. Note here that configuration files for different environments are distributed along with the code.

The configuration administrator, following the tag in the previous step, checks out the live code, configures the IDC test environment, builds, packages (MVN, ANT)(PHP does not need to be packaged), and then distributes to the unified distributor within IDC.

Configure the administrator or SA line personnel to push the content of the distributed program code to the relevant test server (package name such as idc_test.war), and then inform the developer and tester to test. If any problem occurs, roll back to the top and continue to modify.

Checkout the tested code, configure the IDC environment, compile, package (MVN,ant)(PHP does not need to package). Then release the data to the UNIFIED distribution server in IDC for batch release.

Configure the administrator or SA online personnel to push the distribution content to the relevant official server (package name such as idc_product.war), and then notify the developers and testers to test. Issue the rollback command directly if there is a problem.

IDC is launched for JAVA programs, the process of grouping may be AB group launched the train of thought, namely smooth off half of the server, and then released updated the code, restart the test, no problem, hang up the updated server, at the same time again smooth rolled off the other half of the server, and then released updated test code (or directly after the release, restart, hang up the line)

4. Specific scheme of PHP program code going online

For PHP online method: publish code (also need to test the process) can be directly published to the official line temporary directory, and then mv or change link to publish to the official line directory, without restarting the HTTP service. This is the launch plan of Sinlang market.

5, Java program code online specific scheme

For Java rollout methods: Larger companies need to group the rollout smooth (such as removing half of the server from the load balancer), release the code, restart the server for testing, and when it works, put half of the line up, and then put the other half down. If the front DNS intelligent resolution, online can also be divided into regions online a number of servers, gradually spread to the national server, this is called “gray release”, in the back of the portal website online knowledge we are in the explanation.

6. Code on-line solution matters needing attention

In the online process, office test environment –>IDC test environment –> formal production environment, all software in all environments should be unified version, followed by as single as possible, otherwise there will be endless problems, the development and test success, IDC test may have problems (such as: operating system, Web server, JDK, PHP, Tomcat,resin and other versions)

The development team tests the internal test environment (the test environment is maintained by the development team or automatically updates the code regularly). If the code has problems, it will be returned to a developer for re-development.

There are special test engineers. If the program has problems, it will be directly returned to the developer (the returned bugs are generally the program, called BUG library), and IDC will test if there is no problem

IDCtest involves testers and operation and maintenance personnel, called IDCtest, to carry out the pressure test of the program. If there is any problem, it will be directly returned to the developer, and if there is no problem, it will go online.

Several server code distribution on-line scheme example (JAVA program)

A: Assume that there are six service servers. Divide the servers into group A and GROUP B, group A has three servers, and Group B has three servers. Smoothly disconnect group A from the load balancer.

B: The offline process is to kick the group A server out of the RS pool (LVS,NGINX,HAPROXY,F5 and other smoothing schemes) by script, so as to avoid the load balancer sending the request to the group A server (the time at this time should be when the website traffic is low, usually at night).

C: the code distribution to group A directory server site, online for A set of server and restart the service, and accessed by professional testing personnel test, after the success of the test, hang up the group A server, server offline group B at the same time, group B code online operating test is the same as the group A, also want to watch online services during the period of the server status, the problem is rolled back in time.

If it is a PHP program, the on-line can be simplified, directly on-line code (preferably full) published to all on-line server specific directory, after the completion of distribution, one-time MV or LN to the site directory, of course, the test is also indispensable. In addition to human tests, there are various test scripts that test the various related business interfaces.

Understand continuous integration, continuous delivery, and continuous deployment

The continuous approach to software development is based on automatic execution of scripts to minimize the possibility of introducing errors when developing applications. From development to deployment of new code, they require little or no human intervention. It involves constantly building, testing, and deploying code changes in each small iteration, reducing the opportunity to develop new code based on a flawed or failing previous version. There are three main approaches, continuous integration, continuous delivery, and continuous deployment, each applied according to the strategy that works best for you.

  • 1. Continuous integration

Code merges, builds, deploys, tests all together, executes the process constantly, and gives feedback on the results.

Continuous integration (CI) is a software engineering process that integrates copies of all engineers’ work on software onto a common mainline several times a day.

Grady Booch first proposed the term in his layout method, but he did not mention integration several times a day. It later became part of Extreme Programming, or XP. In test-driven development (TDD), automated unit testing is often accompanied.

Continuous integration is mainly proposed to solve the problems faced by software in system integration. Extreme programming calls these problems integration hell.

Continuous integration focuses on building and (unit) testing as soon as developers submit new code. Based on the test results, we can determine whether the new code and the original code are correctly integrated. In a nutshell: integrate code into the trunk frequently (multiple times a day).

The purpose of continuous integration

Finding integration errors early and easy to track because the revisions are small can save time and cost on a project.

Avoid confusion in the last minute of the release date, when everyone is trying to check for the little incompatibilities they make.

When a unit test fails or an error occurs, if the developer needs to restore the code base to a problem-free state without debugging, only a small number of changes (due to the frequency of integration) need to be discarded.

Keep “up to date” programs available for testing, demonstration, or distribution.

Frequent code submissions encourage developers to create modular, low-complexity code.

Prevent branches from straying too far from the trunk. If you do not integrate frequently, the trunk is constantly updated, which can make later integration difficult or even difficult.

  • 2. Continuous delivery

Deploy to test environment, preproduction environment

Continuous delivery (CD) is a software engineering technique that enables the production process of software products to be completed within a short period to ensure that software can be stably and continuously released at any time.

The goal is to build, test, and release software faster and more frequently. This approach can reduce the cost and time of software development and reduce risks.

Continuous delivery Is based on continuous integration, where integrated code is deployed to production-like environments that are closer to the real world. For example, after we finish unit testing, we can deploy the code to a Staging environment that connects to the database for more tests. If there are no problems with the code, you can continue to deploy it manually into production.

3. Continuous deployment releases the final product to a build environment for users to use

Continuous Deployment (CD), the next step in Continuous delivery, refers to the automatic Deployment of code to production after it has been reviewed.

Continuous deployment is sometimes confused with continuous delivery. Continuous deployment means that all changes are automatically deployed into production. Continuous delivery means that all changes can be deployed to production, but not for business reasons. Continuous delivery must be implemented if continuous deployment is to be implemented.

Continuous deployment is the automation of deployment to production on a continuous delivery basis.