Continuous Delivery with a multi-module application

[Paul Rule]

Hi, 

I'm new to CD. The presentation here http://www.slideshare.net/wakaleo/continuous-deliverywithmaven explained it very well, and I've been reading some of the posts in this group and at http://devopsnet.com/ - but there are a few things that haven't been explicitly stated that I'd be interested in confirming (if they are explicitly discussed somewhere, please let me know!):

I'm using Maven3, subversion, multiple modules, multiple applications, common modules.

1. When using CD, do you just have one build pipeline to build the entire application (eg trigger the build from the parent of a multi-module maven project). So if there is a change to any module, the app tries to build, stopping on the first failed module or succeeding to produce the app 

2. In order to do this, are you implying that there would just be the one svn structure:

/trunk/app1

  /module1

  /module2

  /module3

as opposed to having trunk/tags/branches for each module.

3. When you have shared modules do you create a separate repository and pipeline for those and just use 'mvn versions:use-latest-versions' in your applications to pick up the latest version?

4. I assume tagging is a thing of the past? It is simply a case of tracking the repository version number?

5. I assume branching is only done at the application level (which by definition includes all of its submodules) for support reasons?

I hope I've explained myself okay here. 

Thanks.

references:

http://mojo.codehaus.org/versions-maven-plugin/use-latest-versions-mojo.html

http://www.slideshare.net/wakaleo/continuous-deliverywithmaven

[Tim Brown]

On Thu, Apr 17, 2014 at 7:40 PM, Paul Rule <paul...@gmail.com> wrote:

Hi, 

I'm new to CD. The presentation here http://www.slideshare.net/wakaleo/continuous-deliverywithmaven explained it very well, and I've been reading some of the posts in this group and at http://devopsnet.com/ - but there are a few things that haven't been explicitly stated that I'd be interested in confirming (if they are explicitly discussed somewhere, please let me know!):

I'm using Maven3, subversion, multiple modules, multiple applications, common modules.

1. When using CD, do you just have one build pipeline to build the entire application (eg trigger the build from the parent of a multi-module maven project). So if there is a change to any module, the app tries to build, stopping on the first failed module or succeeding to produce the app 

2. In order to do this, are you implying that there would just be the one svn structure:

/trunk/app1

  /module1

  /module2

  /module3

as opposed to having trunk/tags/branches for each module.

I'd only have independent repositories (trunk/tags/branches) for independently releasable components.    So, if the modules are something releasable (not normally a jar), then yes #1 and #2 are correct.

If the modules were releasable then I'd have a component pipeline per module, that fans-in to a deployment pipeline (which would also have a src input for the app itself).

3. When you have shared modules do you create a separate repository and pipeline for those and just use 'mvn versions:use-latest-versions' in your applications to pick up the latest version?

Repository - not necessarily.   I generally like to think that if a module passes it's unit tests it is fit for consumption.  Wherever that module is built & assembled, if it passes unit tests push it to your standard repository.

You don't need to have a distinct pipeline if that module is part of another set -- i.e. ApplicationA produces a shared component.  If however it's "common" then you might have a short pipeline of common modules.  (FWIW, naming anything "common" means it becomes the catch-all.  It'll get filled with crap, and you'll find all your apps depend on it.  Then, anytime one of these common modules changes you end up building your entire damn stack.   I guess I"m saying -- avoid having anything labeled as common ;-)

 

4. I assume tagging is a thing of the past? It is simply a case of tracking the repository version number?

Track the revision.  No need to tag IMHO.  I have seen people tag in arrears -- when the app pushes to staging they go back and tag/create a release branch so they have a place to put defect fixes. 

5. I assume branching is only done at the application level (which by definition includes all of its submodules) for support reasons?

Yup.

[Andrew Swan]

Hey Paul,

Welcome to the CD group. The Jez Humble et al book is definitely worth a read if you haven't already. It won't answer your maven-specific questions, but it gives a good grounding in the principles.

Cheers,

Andrew

--
You received this message because you are subscribed to the Google Groups "Continuous Delivery" group.
To unsubscribe from this group and stop receiving emails from it, send an email to continuousdeliv...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paul Rule]

Thanks, I'll be reading that - I hope it goes over these points, but I usually find in books that the details are skipped over (*OR* I'm missing something and can't see the wood for the trees).

To unsubscribe from this group and stop receiving emails from it, send an email to continuousdelivery+unsub...@googlegroups.com.

[Paul Rule]

Thanks for your answer, it helps a lot. 

[Andrew Swan]

Hi Paul,

You (and others on this list) might find this blog post useful too:

http://blogs.atlassian.com/2014/04/practical-continuous-deployment/

Disclaimer: I work for Atlassian

Cheers,

Andrew

--

You received this message because you are subscribed to the Google Groups "Continuous Delivery" group.

To unsubscribe from this group and stop receiving emails from it, send an email to continuousdeliv...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

“Reality provides us with facts so romantic that imagination itself could add nothing to them.” 
― Jules Verne

[Paul Rule]

Thanks Andrew.

To unsubscribe from this group and stop receiving emails from it, send an email to continuousdelivery+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.