Getting A Build Process In Place

L

Lee Theobald

Hi all,

I'm trying to get our company build process a little more automated and would appreciate some feedback on where to direct our attention. The current build process works as follows:

- Projects are normally web applications packaged in wars. We use Maven tomanage dependencies etc. & the code is stored in SVN.
- Within our pom.xml, we have a number of Maven profiles. There is normally a "shared" profile that contains the majority of the configuration for the application (put in place with the resources plugin) followed by a more environment specific profile (dev, staging, production etc.) containing additional information.
- When it comes to building for an environment, a developer will build a war file on his local machine using a machine command similar to "mvn -P shared,production clean package".
- This gives the developer a war file. They then SCP these up to the relevant server, extract to a Tomcat & restart that Tomcat.

This is working fine but there's a lot of room for improvement. Recently we've looked at using Jenkins for continuous integration but haven't got toofar with it.

So here are the points I'm wondering about:

1) Are Maven profiles the best way of storing this specific environment? The pom's are certainly getting bloated with a lot of configuration & this can be quite intimidating to a newbie. Any suggestions on alternatives
2) The whole devops movement seems to be something that could help me out here but I'm not too sure where to start. I've heard about a pipeline usingsomething along the lines of Maven --> Jenkins --> Puppet working well. With Jenkins handling the build & Puppet deploying. Does anyone have any experience with this?

Cheers for any input
Lee,
 
A

Arne Vajhøj

In my personal opinion, although Maven does a pretty good job of
dependency management, it's not a very good _build_ tool, in part
because Maven's profiles is a cumbersome, awkward way to manage
environment configurations.

I much prefer the new generation of build systems such as Gradle or
Buildr which combines Maven style dependency management and sensible
defaults with a programmatic approach. (That said, the greater
flexibility and ease-of-change of these tools might require a little
more self-discipline when developing the builds of your projects to
keep them from becoming a mess of special rules and exceptions.)

I would be tempted to say that the biggest problem of Maven is
that it has to be "the Maven way" and the biggest benefit of Maven
is that it has to be "the Maven way".

:)

Arne
 
R

Roedy Green

I'm trying to get our company build process a little more automated and wou=
ld appreciate some feedback on where to direct our attention. The current =
build process works as follows:

The way I do it is use a Java program to stomp out ANT scripts. This
way I have to specify a bare minimum to build a project and I can
change the way every build script works by changing one line of code.

ANT is very quick at compiling because it loads javac only once. It
also has GenJar which figures out by itself what to include in the
Jar.

I can't compare it with Maven. Maven docs did not speak to me in the
terms I wanted to understand what it does before I would invest in the
learning curve.


ANT is preposterously verbose, but at least is its comprehensible.
 
F

Fredrik Jonson

In said:
I'm trying to get our company build process a little more automated and
would appreciate some feedback on where to direct our attention. The
current build process works as follows. Projects are normally web
applications packaged in wars. We use Maven to manage dependencies.

I agree that using profiles in maven builds is rather verbose and not very
simple to work with. I'd almost consider profiles a necessary evil that should
only be considered as a feature of last resort.

Have you considered using separate modules, all depending on or using the
base project as a parent? I think this approach is easier, it is straight
forward to understand that a separate module has different configuration
files, compared to how hard it is to perceive how a combination of profiles
affects a build.

What I usually do is to have a base module that contains the source code and
the development environment configuration. Then you have separate modules
for the integration test environment and production environment, each with
their set of configuration files that overrides the ones in the base module.

If you want to you can set this up as a multi module project, ie parent that
contains submodules development, integration, and production. Though
multi-module projects have their own gotchas, so if you want to keep it
simple, start by just make separate standard modules with dependencies.

BTW, I hope you are aware that when you declare a dependency of type war,
the war is unpacked, including web resources, in the dependent project. That
means that your jsp-files can be maintained in the base module, they do not
have to be copied or version managed separately in the dependent modules.

https://maven.apache.org/plugins/maven-war-plugin/overlays.html

Using Jenkins is indeed a good idea too. Though the purpose of using a
continuous build system, to me at least, is orthogonal to the goal of
having a transparent build configuration. Jenkins runs the slow and boring
integration tests and reminds you that you forgot to add that new source
file in your last commit before you pushed. It doesn't by it self make your
build configuration more understandable.

Maybe even the opposite? If you set up Jenkins to compile your rather
complicated build targets, so that you seldom have to do it yourself, then
you are confronted with that complexity less often and forget how it works.
You might end up with a cargo cult based build configuration.
 
A

Arne Vajhøj

The way I do it is use a Java program to stomp out ANT scripts. This
way I have to specify a bare minimum to build a project and I can
change the way every build script works by changing one line of code.

Ant has built in ways to achieve that.

Arne
 
L

Lee Theobald

Thanks for the responses everyone. You've given me a few threads to investigate.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top