How better in fine-grained micro-architecture services. Speaking from here will be continuous integration and continuous delivery.
1. Introduction to Continuous Integration
CI (Continuous Integration, Continuous Integration)
CI codes to ensure new and existing code to integrate submitted to ensure everyone in sync. CI server detects
Code has been submitted and checked out, and then take the time to verify if the code compile and test can be passed.
As part of this process, we often generate some constructs (artifact) used for subsequent verification.
Ideally, the construct should be generated only once, and then used in all aspects of this submission to deploy the corresponding.
CI's many benefits . Through it, we can get fast feedback on code quality to some extent.
CI can be automated to generate a binary file. All codes used to generate these constructs are under version control,
So, if desired, can be regenerated version of this construct. By CI we can construct from a deployed back to
Corresponding code, some CI tool, it is also possible to build the code and the run-off test was visualized.
Continuous integration allows us to more quickly and easily modify the code.
Some tasks using the CI CI tool even adopted this practice, in fact, only the tool is not enough.
Test whether people really understand the three issues of CI?
- Do you check in code to the mainline every day?
You should ensure that the code can be integrated with existing code
- Do you have a set of tests to validate the modifications?
If you do not test, we only know that no syntax errors after integration, but does not know whether the behavior of the system has been destroyed.
CI does not validate the code of conduct is not a true CI.
- When the build fails, whether to repair the CI team as the first priority of things to do?
Green building means that we have to modify the existing code safely and integrated together. Red means the building, last modification is likely to have a problem,
Then fix the code can only be submitted built.
2. Continuous integration is mapped to the micro-service
As mentioned earlier, each micro-services should be deployed independently of other services.
So how micro-services, CI source code to build between three and establish appropriate mapping it?
The easiest way, as follows
Figure 6-1 all micro-services in the same code base, and only one building
On the surface, this method is much simpler than other methods: the code base is relatively small because you need to be concerned,
And Conceptually, this building is relatively simple. Developers work has also been simplified:
We only need to submit code, If you need to work on multiple services, it can get a submission.
In the simultaneous release (lock - step release), you need to deploy multiple one-time service.
In general, we absolutely should avoid this pattern, but early in the project is an exception.
When only one team working on all services, this model is acceptable in a short time.
There are many obvious shortcomings of this model.
If I only changed one line of code in Figure 6-1 User Service, and all other services need to be validated and build,
In fact they probably do not need to re-verify and build, so here we spend unnecessary time.
To make matters worse, I do not know what constructs should be redeployed and which should not.
Organized this way, often deployed mode will return to all the code, and this is what we are do not want to see.
Unfortunately, if you modify this line cause the build fails, then it is repaired before building other services related code can not be submitted.
A variant of this method is to keep a code base, there are a plurality of CI will be mapped to different portions of the code base, respectively.
Figure 6-2
This model is a double-edged sword.
On the one hand it will simplify the checkout / checkin process, but on the other hand, it makes you think and submit changes to multiple services
It is a simple matter, so as to make changes to multiple services coupled together.
But with respect to more than one service is only one built, this method has been much better.
There is also a good way, each service has its own micro-CI, the micro-services so that you can do a quick verification before deploying to a production environment.
Figure 6-3
Here each service has its own micro-code base, respectively, in the corresponding CI binding.
When modifying code library can be constructed and run wherein only relevant test.
Each service has its own micro-code base and build process.
We also use CI build process, to create a fully automatic, then constructs for deployment.
6.3 Construction of the pipeline and continuous delivery
。。