SVN and Maven and Jenkins (GO)

Currently the project team is developing a project consisting of multiple submodules, the build tool is Maven, and the version Control tool is SVN. This article wants to make a little tentative idea of how to use Maven and SVN together. 

First, only the SVN situation 

First consider the situation without MAVEN. In this case, each developer of the project team needs to check out all the source code locally. 

You need to update the code for the perimeter project before each commit. Since the project is dependent on each other, it is likely that all the code will be updated again. In a situation where the project relies on confusion, it is more troublesome 

is to say that the collaboration between project team members is a SVN-centric 

The disadvantage of this approach is that: 

1, the developer needs to have all the code locally, the compilation speed is very slow 

2, if someone else is responsible for the module error, will affect their own development. If the project is relatively large, the problem of the module that others are responsible for, you can not actually solve 

The advantages of this approach are: 

1, before committing to do a full-volume update, equivalent to do a local full-scale compilation, submitted to SVN basically can be guaranteed that there will be no compile errors. I call it "pessimistic commit", similar to the "pessimistic lock" in the database. 

2, because the local have all the code, so the local build comparison is not prone to error 

Second, the introduction of the MAVEN situation 

One of Maven's main roles is support for modular development 

Developer a machine can only project A, Developer B machine only project B, where Engineering B relies on engineering a 

As long as project A has been deploy to a remote repository, Project B can be built locally without the need for engineering a code. In other words, every developer locally, only need to checkout their own project 

The advantages of this approach are: 

1, each person only own responsible code, the local construction speed is fast 

2, if the other module construction error, the module is not easy to affect their own 

3. Clear delineation of responsibilities 

The disadvantages of this approach are: 

1, the building of high-rise modules, dependent on the lower-level modules. Because developer B has only project B code locally, if Project A has not been deploy to the remote repository, then Project B cannot be built locally 

2. After being submitted to SVN, it is possible to create a full-volume compilation failure on SVN. For example, a deletes a method and submits it to SVN, but does not deploy. Then B is built locally based on the old component of the A module, and the code is submitted after success. In this case, compiling on SVN is not possible. 

To avoid these problems, I feel that there are 2 rules to follow in the project team: 

1, the code is submitted, you need to deploy the module into the remote repository at the same time. To avoid inconsistencies between the components of the remote repository and the SVN source code 

2, need to set the component Update policy to always in the POM 

XML code

1. <</SPAN>snapshots>
2. <</SPAN>enabled>true</</SPAN>enabled>
3. <</SPAN>updatePolicy>always</</SPAN>updatePolicy>
4. </</SPAN>snapshots>

The above 2 provisions, the first is to resolve the issue of inconsistencies in submissions, the second is to resolve the problem of obtaining inconsistencies. The goal is to avoid build success, but the problem of full compilation failure on SVN 

Because it was submitted first, and then found out if SVN compilation failed, so I call it "optimistic commit" 

Third, Comparison 

In general, the difference between the two approaches is the key: one is local with all the code, and the other is only the local code that is responsible for it. 

For small projects, this problem does not exist. But if it's a bigger project, I think the latter is better, but it introduces some additional issues that require the project team owner to follow the rules to avoid 

Iv. introduction of CI 

Together with SVN and maven, if you introduce CI, you can make this process easier 

After a successful local build, the developer submits the code to SVN, with the CI system, such as Hudson (Jenkins), to perform the Deploy action 

Alternatively, use the SCM plug-in to bind to the Deploy phase. After the deploy succeeds, the plugin completes the action of submitting the SVN. This also guarantees the submission of SVN and deploy consistency 

If the full compilation fails on SVN after the commit, the CI system will also notify the relevant person the first time 

V. Summary 

In general, I think there are the following points: 

1, recommend the use of sub-module development method, each developer only check out their own responsible code 

2. Set the snapshots update policy to always 

3, with the CI system or SCM plug-in, to ensure the consistency of check in and deploy 

4, rely on the CI system, in time to find the SVN compilation errors

SVN and Maven and Jenkins (GO)