How to continuously build and deploy feature branc

问题:

My team is using feature branches to implement new features and continuously deploys snapshot builds into a remote repo for our users to use. Thus 'deploy' really only means 'distributing to a remote Maven repository'. We're currently only running continuous integration builds for the master branch and not the feature branches for the following reason: we're using Maven to build our projects and distribute the JavaDoc and sources alongside the JAR.

My plan was now to add a classifier to each feature branches build and expected that one to be used when creating and deploying the artifacts like this:

• Branch: master
• Classifier: none

• Artifacts: foo-${version}.jar, foo-${version}-sources.jar, foo-${version}-javadoc.jar

• Branch: feature-X

• Classifier: myfeature
• Artifacts: foo-${version}-feature.jar, foo-${version}-sources-feature.jar, foo-${version}-javadoc-feature.jar

I don't really care about the exact naming of the artifact, I just need separate main, source and JavaDoc artifacts for the feature branch. It turns out, neither the JavaDoc plugin nor the source plugin consider the classifier configured and thus effectively overwrite the artifacts created for my master build.

I don't really want to change the artifactId although this would probably solve the issue. How do you approach feature branches and continuous integration with Maven?

回答1:

I would suggest to add the branch-qualifier into the version component, as it is more related to that part. This also allows your snapshot dependencies on those versions alongside the main branch.

回答2:

I would suggest to use an appropriate version which represents the branch as well as the version things like:

1.0.0-SNAPSHOT for master

and

1.0.0-F1-SNAPSHOT for feature F1

etc.

This give also an indicator from which release 1.0.0 the feature branch has been made.

回答3:

Using the version number to store the branch name, as suggested by others, is a quick win, but leads to problems if you use version ranges. The version number was not meant to be used like that. We use them in a continuous integration process to make the integration tests depend on the tested artifact:

[1.8-SNAPSHOT,1.9-SNAPSHOT)

The qualifier part inside the version number denotes different incremental stages of the same code base:

1.8-alpha1-SNAPSHOT
1.8-alpha1-SNAPSHOT
1.8-beta1-SNAPSHOT

This is why the version range above will capture the above and Maven will order them in this order:

1.8-SNAPSHOT
1.8-alpha1-SNAPSHOT
1.8-alpha1-SNAPSHOT
1.8-beta1-SNAPSHOT

Any artifact carrying the feature branch name in the version number (1.8-featureA-SNAPSHOT) will be ordered newer than the snapshots without qualifier. But a feature branch is a 'different' code base, not a newer representation of the same code base. For our integration test scenario this led to useless test failures. The feature branch was not ready yet to be tested by integration tests.

We now follow this rule: if you have to change something anyway, why not the artifact id? We change the artifact id for feature branches and it works just fine.

回答4:

Instead of altering the maven coordinates of the artifact you could use maven-branch-extension to effectively create a separate SNAPSHOT namespace for each of the feature branches. Quote from the project page:

Instead of changing the version number when on a feature branch, we change the repository. Each feature is deployed into a subdirectory, based on their branch name, in a remote repository that is only for feature branches. There is no risk of artifacts being overwritten. Version numbers do not change. Branching and merging with Git stays simple (like it was meant to be!).

The extension gets the current Git branch and resolves a property in the URL of the repository so that artifacts can be stored and retrieved correctly. It also manages caching and fetching of artifacts to the local repository so that artifacts are taken from the feature branch repository, if they exist, when working from a feature branch.

The beauty of this is that external users of the SNAPSHOT dependencies are completely isolated from the internal work on topic branches.