I've worked on several large 'enterprise' projects, several could have been 4-6 projects in their own right so maybe 12 ear's, one had 120 pom files. Lucky it got refactored and split into I think 40 repos.
I would suggest; ) branching, using git flow method. ) jgit-flow plugin (https://bitbucket.org/atlassian/jgit-flow), not maven-release-plugin ) deployment, now only using Ansible as finding easier to use than chef/puppet ) versioning, using http://www.mojohaus.org/build-helper-maven-plugin/parse-version-mojo.html have a release profile in the companies parent pom ) for code quality, using atlassian stash which is forcing 1 successful build and 1 approver before for code to be merged into develop, successful build also means code, test, findbugs etc. ) cim, still using jenkins v1, not upgraded to v2 yet. have a mix of jobs, most deployable artifacts have a pipelines checking develop and waiting for 15 mins before kicking off a build to allow multiple merges, then automatically building, deploying and configuring using ansible to the development environment, running qa step(s) either cucumber or selenium, if they all pass then automatically creating a release candidate and closing the release branch and merging into master ) 1 git repo for each deployable artifact ) git repo for shared code/framework, logically group so not all in 1 repo but not all with their own repo. ) each logical cucumber project was it's own git repo, so if it changed it was easier to automatically trigger it's execution ) jenkins or what every cim you pick, use multiple slaves to run the tasks, yes you could get everything running on the master jenkins node but it will quickly become overload. ) this is how I do release, with the mvn -Pdo-release -N validate, it will bump the version numbers create the release branch, automatically finish it, tag it, so develop branch always see -SNAPSHOT's and master never sees -SNAPSHOT's http://pastebin.com/DbAGACk7 John On 30 November 2016 at 18:44, Karl Heinz Marbaise <khmarba...@gmx.de> wrote: > Hi, > > > > On 30/11/16 19:18, Florian Schätz wrote: >>> >>> A library project to be >>> shared between multiple applications each having its own release-cycle >>> should not be part of a multi-module project used to build such an >>> application and should be an independent project with its own >>> release-cycle. >> >> >> While this is of course a good idea, especially when starting to create >> new applications, the library projects will grow with the applications >> and not independently of them. We cannot start by first investing months >> to create the perfect will-work-for-ten-years library and only then >> start coding the application that will, in the first months, only use >> 10% of all these features. So, realistically, during a development >> cycle, both the application and the library will grow... (which doesn't >> mean that we cannot separate them) >> >> Which leads me, for example, to the problem that I still want to >> automate as much as possible. I would like, for example, to click one >> button in my build server, perhaps enter some parameters and get a new >> release candidate of the libraries from the current release branch, >> update the dependency version of the application to this rc version, >> make the application an rc (from the application's release branch), >> install them both into the repository, tag the current status on git and >> deploy the rc application onto the server. >> >> Especially for bigger projects, I want to keep the amount of manual work >> needed as small as possible. As much building should be done >> automatically, if possible. And I would like not having to code a >> jenkins or maven plugin for that purpose (but of course, I would, if >> needed, no problem there). > > > > You can simply use maven-release-plugin (in Maven itself) which you can used > to fully automatically create releases of your project...This will need > only a plugin in Jenkins which handles all those stuff...correctly > configured things like scm entries in your pom file tagging in Git will be > done as well.... > > Sometimes you might need to improve that using the versions-maven-plugin in > combination with some pipeline steps in Jenkins...which prevents some > drawbacks of the maven-release-plugin.... > > > May be you need to think about using the Maven integration in Jenkins or > using freestyle projects or better start using pipelines ...(I often > observed performance drawbacks in relationship with Maven integration in > Jenkins)... > > > https://wiki.jenkins-ci.org/display/JENKINS/M2+Release+Plugin > https://wiki.jenkins-ci.org/display/JENKINS/Release+Plugin > > > Kind regards > Karl Heinz Marbaise > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
