Bulldozed stage is an extremely complex distributed system, the whole system includes the RPC calls, cache, cluster synchronization all sorts of complex scenes, such as the whole team are only 20 individuals while maintaining the nearly module development and testing work, if there is no a set of effective mechanism, it is hard to imagine how to accomplish these tasks, continuous integration plays a very important role, with the aid of Git, Docker, Jenkins and Nexus tools, we set up our own continuous integration environment, and step by step for its own best practices, this article will share how we use these technologies increase the productivity of the team,
Push the continuous integration system of
Using git as version control repository
Compared to the similar project version system, git has a very significant advantages, is the merge version branch (branch) (merge) is very convenient,
Use the docker build test environment
As a new way of virtualization, compared with the traditional way of virtualization has many advantages, for example, the docker virtual container start can be realized in the second grade, and the system resource utilization is very high, in addition, the management of the docker, migration and extension are also more effectively,
Using Jenkins as a continuous integration server
Jenkins provides developers with very effective last set management, its powerful plug-in system and the construction of its clear logic, makes the build process to create a very simple,
Docker role in continuous integration system
Testing as an important part of software projects, typically require development team to build a set of independent testing system, but as a link in a continuous integration, this test system is different from the general testing system, the main reason for, continuous integration test system is mainly used to do regression testing, and need to support a lot of code to upgrade quickly, on the basis of the characteristics of docker, as well as the demand of the continuous integration, a push the docker built a set of test system for continuous integration,
Mirror preparation: docker operation based on the image, and image file for each situation is different, so you need to independent analysis of each project demand and future expansion needs, to create different versions of the image file, at present, a push image, there are mainly four categories respectively support the front-end and back-end, tools and so on, before the end, for example, a push separation adopted before and after the end of development mode, so the image is mainly used to support the web front-end service running,
Service pack preparation: the service to run in the docker need, need docker instance installed in the corresponding service pack (service package), generally there are two ways, one is the corresponding service package installed in the image file, another in the form of a docker volume dynamic map to the docker instance, two ways has its advantages and disadvantages, the first way makes every docker container start very fast, and the second way is more flexible, this need according to different needs to choose the appropriate way,
Docker is illustrated below in the role of the continuous integration system, Jenkins as the primary server will code and the docker unified management,
Push a continuous integration process
Below the user module, for example, elaborates the process of continuous integration, as shown in the figure below:
Can be seen from the graph, we system git branch including dev, master two branches:
Dev: development branch, developers maintenance, developers will be submitted to the latest code branch, Jenkins monitor this branch, any code change will trigger the automated test
Master: release branch, the branch are the version on the test automation through after version, and automated packaging to monitor this branch
Figure in which each rectangle represents a Jenkins Job, below for each Job description:
? Dev branch of library user: monitoring the user code, each time a new code is submitted, you will automatically trigger build tasks, compile the code, the generated code style at the same time, the test coverage reports about code quality, such as after the success will trigger user - docker task,
? User - docker: packaging engineering, the user to restart the user of the docker instance to use new user package, after the success will trigger the testcase task
? Testcase: acceptance testing, testing whether they meet the business requirements defined acceptance criteria, after the success would trigger marge task
? Dev branch of the merge: will the user merge into the master branch
? User - PKG: monitoring the user master branch of the code base, when a code change, execute MVN package packaging operations
After the above steps, from the code submitted to the packaging of the entire process is automated,
Conclusion
Now more and more companies begin to pay attention to continuous integration system, but the lack of customization system can really meet the needs of complex? When the module is more and more complex, the relation between the frequency of the integration is more and more big, the running environment of rising, and so on, the lack of custom continuous integration system can achieve expected, a push on the docker found a solution, although there are still many challenges, but as the technology upgrade and improve, we will do better more,
CodePudding user response:
This article should be published to the blog instead of BBSCodePudding user response:
Refer to this and see how to customize:http://blog.csdn.net/lee790608/article/details/51559970
My QQ 280775561, WeChat JohnLee790608, peer can discuss,
CodePudding user response: