You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Eric Kolotyluk <er...@gmail.com> on 2013/03/01 22:26:28 UTC
Deployment
A while back we had some interesting discussions on using Maven, or
maven-like technology for deploying production software. I was wondering if
anything new has been happening since then.
Basically what I am hoping to see is a generic installer framework that
bootstraps deployment of a production system or service the way Maven
bootstraps a development environment.
Can anyone point me to anything happening on that front?
Cheers, Eric
Re: Deployment
Posted by Stephen Connolly <st...@gmail.com>.
Chef or puppet?
On Friday, 1 March 2013, Eric Kolotyluk wrote:
> A while back we had some interesting discussions on using Maven, or
> maven-like technology for deploying production software. I was wondering if
> anything new has been happening since then.
>
> Basically what I am hoping to see is a generic installer framework that
> bootstraps deployment of a production system or service the way Maven
> bootstraps a development environment.
>
> Can anyone point me to anything happening on that front?
>
> Cheers, Eric
>
Re: Deployment
Posted by Eric Kolotyluk <er...@gmail.com>.
On 2013-03-03 9:35 AM, Graham Leggett wrote:
> On 3 Mar 2013, at 16:24, Ron Wheeler <rw...@artifact-software.com> wrote:
>
>> I have a hard time seeing how Maven can be bent to do this without making maven even more complex.
> In my experience, maven has all the tools needed already out the box, the problems I encountered while doing it were bugs, which I fixed and contributed back to maven.
>
> Key to this is use the tools appropriately. Maven is good at building and releasing, rpm/deb/yum/apt-get are good for packaging and deployment, while puppet/chef are good for managing whole boxes.
I agree, the point is not to add to or change Maven, the point is to
effectively use the Maven we already have. No bending required :-)
>
>> I think that preparing deployment artifacts such as RPMs and windows msi or exe files that are based in idividual platform and customer configurations requires a lot more information than maven should know about.
> Configuration can be just as complex as code, you reach a point where constantly trying to roll configurations by hand is just too time consuming and error prone.
>
> Modern OSes come with the ability to install and roll back software atomically, extending that to configuration is a logical next step. The configuration may be general, or it may be specific to a given environment, either is possible.
>
> Regards,
> Graham
> --
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Deployment
Posted by Graham Leggett <mi...@sharp.fm>.
On 3 Mar 2013, at 16:24, Ron Wheeler <rw...@artifact-software.com> wrote:
> I have a hard time seeing how Maven can be bent to do this without making maven even more complex.
In my experience, maven has all the tools needed already out the box, the problems I encountered while doing it were bugs, which I fixed and contributed back to maven.
Key to this is use the tools appropriately. Maven is good at building and releasing, rpm/deb/yum/apt-get are good for packaging and deployment, while puppet/chef are good for managing whole boxes.
> I think that preparing deployment artifacts such as RPMs and windows msi or exe files that are based in idividual platform and customer configurations requires a lot more information than maven should know about.
Configuration can be just as complex as code, you reach a point where constantly trying to roll configurations by hand is just too time consuming and error prone.
Modern OSes come with the ability to install and roll back software atomically, extending that to configuration is a logical next step. The configuration may be general, or it may be specific to a given environment, either is possible.
Regards,
Graham
--
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Deployment
Posted by Ron Wheeler <rw...@artifact-software.com>.
I have a hard time seeing how Maven can be bent to do this without
making maven even more complex.
I think that preparing deployment artifacts such as RPMs and windows msi
or exe files that are based in idividual platform and customer
configurations requires a lot more information than maven should know about.
Some of this probably attaches more to the corporate ERP (customer info,
options purchased) than to the code generation and dependency
information that Maven usually deals with.
At some point in a product's maturity, developers stop being concerned
with who has bought the product and what platform the client uses and
this moves to a fulfillment/support group that is client oriented.
It is probably a good idea to build a system that manages the client
information relating to configuration and use this to feed files and
installer instructions to existing installer builders that build custom
installers based on the client's desire (OS, branding, configuration)
Ron
On 03/03/2013 6:59 AM, Graham Leggett wrote:
> On 3 Mar 2013, at 03:56, Eric Kolotyluk <er...@gmail.com> wrote:.
>
>>> Modern OSes come with installation systems out the box, and operations people already understand those existing systems, there needs to be a very compelling reason to deploy some software using the platform's own deployment mechanism, and other software via a different system.
>> I wish this were so, but I can easily think of a half a dozen different ways software gets installed or deployed on Windows. Some people use .msi files, other people use InstallAnywhere, and there are all kinds of different mechanisms.
> This isn't a problem that I can see, ideally maven should support all of them, but it is good enough that maven should support just one.
>
> Regards,
> Graham
> --
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Deployment
Posted by Graham Leggett <mi...@sharp.fm>.
On 3 Mar 2013, at 03:56, Eric Kolotyluk <er...@gmail.com> wrote:.
>> Modern OSes come with installation systems out the box, and operations people already understand those existing systems, there needs to be a very compelling reason to deploy some software using the platform's own deployment mechanism, and other software via a different system.
>
> I wish this were so, but I can easily think of a half a dozen different ways software gets installed or deployed on Windows. Some people use .msi files, other people use InstallAnywhere, and there are all kinds of different mechanisms.
This isn't a problem that I can see, ideally maven should support all of them, but it is good enough that maven should support just one.
Regards,
Graham
--
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Deployment
Posted by Eric Kolotyluk <er...@gmail.com>.
On 2013-03-02 7:02 AM, Graham Leggett wrote:
> On 02 Mar 2013, at 5:40 AM, Eric Kolotyluk <er...@gmail.com> wrote:
>
>> I have been toying with the idea for a while as a software developer who has had to build installers for applications and services, and I am often dissatisfied with the experience I get using other people's installers. At one time I was playing with the idea of my own installer that would be cross platform, but the initial bootstrap would be platform dependent, and install enough platform independent stuff, to do the rest in a standard way.
> Modern OSes come with installation systems out the box, and operations people already understand those existing systems, there needs to be a very compelling reason to deploy some software using the platform's own deployment mechanism, and other software via a different system.
I wish this were so, but I can easily think of a half a dozen different
ways software gets installed or deployed on Windows. Some people use
.msi files, other people use InstallAnywhere, and there are all kinds of
different mechanisms.
>
> The deployment systems that are the most painful are those systems that target a specific language. You can't just get operations to install the software, you have to suddenly turn your operations people into language programmers to figure things out when a deployment goes wrong.
Agreed. Operations people should not have to be software developers,
just specialized computer users.
>
> Ideally I'd like to see maven make it easy to create OS specific installers to offer the best experience for each OS, rather than come up with a competing system.
That is my fantasy too.
>
> Regards,
> Graham
> --
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Deployment
Posted by Graham Leggett <mi...@sharp.fm>.
On 02 Mar 2013, at 5:40 AM, Eric Kolotyluk <er...@gmail.com> wrote:
> I have been toying with the idea for a while as a software developer who has had to build installers for applications and services, and I am often dissatisfied with the experience I get using other people's installers. At one time I was playing with the idea of my own installer that would be cross platform, but the initial bootstrap would be platform dependent, and install enough platform independent stuff, to do the rest in a standard way.
Modern OSes come with installation systems out the box, and operations people already understand those existing systems, there needs to be a very compelling reason to deploy some software using the platform's own deployment mechanism, and other software via a different system.
The deployment systems that are the most painful are those systems that target a specific language. You can't just get operations to install the software, you have to suddenly turn your operations people into language programmers to figure things out when a deployment goes wrong.
Ideally I'd like to see maven make it easy to create OS specific installers to offer the best experience for each OS, rather than come up with a competing system.
Regards,
Graham
--
Re: Deployment
Posted by Ron Wheeler <rw...@artifact-software.com>.
http://blog.artifact-software.com/tech/?p=121
That is how we addressed the issue.
Ron
On 04/03/2013 10:45 AM, Mark H. Wood wrote:
> On Fri, Mar 01, 2013 at 07:40:30PM -0800, Eric Kolotyluk wrote:
>> The part I was not too happy with was my service.jar was this ginormous
>> uber-jar created with the Assembly plug-in. Sure, everything worked
>> perfectly well, and was simple, but when I say ginormous I am very
>> serious. If I had had the time, the next thing I was going to do was
>> have my installer install Maven, and then bootstrap the rest of the
>> pieces by just choosing the right artifact names and versions given the
>> system environment I found. Basically, replace the uber-jar with a
>> common system-wide repository of jars, and configure the classpath
>> appropriately.
>>
>> I am just thinking out loud and trying to get ideas from people.
> If the main thing you want from Maven in this case is dependency
> resolution, consider something like Ivy, which specializes in such.
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Deployment
Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
On Fri, Mar 01, 2013 at 07:40:30PM -0800, Eric Kolotyluk wrote:
> The part I was not too happy with was my service.jar was this ginormous
> uber-jar created with the Assembly plug-in. Sure, everything worked
> perfectly well, and was simple, but when I say ginormous I am very
> serious. If I had had the time, the next thing I was going to do was
> have my installer install Maven, and then bootstrap the rest of the
> pieces by just choosing the right artifact names and versions given the
> system environment I found. Basically, replace the uber-jar with a
> common system-wide repository of jars, and configure the classpath
> appropriately.
>
> I am just thinking out loud and trying to get ideas from people.
If the main thing you want from Maven in this case is dependency
resolution, consider something like Ivy, which specializes in such.
--
Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
There's an app for that: your browser
Re: Deployment
Posted by Laird Nelson <lj...@gmail.com>.
Literally *just* stumbled across Bintray: https://bintray.com/beta
Best,
Laird
On Fri, Mar 1, 2013 at 9:33 PM, Wayne Fay <wa...@gmail.com> wrote:
> > I was not thinking of adding to Maven, rather I was soliciting insight
> > from the Maven community because I value their inventiveness.
> >
> > I am half way toying with the idea of building something myself, but
> > first I want to make sure I am not reinventing the wheel.
>
> Sounds like you have some good ideas. I'd check to make sure Puppet
> and Chef don't have some recipes you could build on top of to help you
> down this path before doing any building from scratch. We use puppet @
> work pretty extensively but mostly on the sysadmin side and less on
> the middleware/apps side - we are not a devops shop.
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
http://about.me/lairdnelson
Re: Deployment
Posted by Wayne Fay <wa...@gmail.com>.
> I was not thinking of adding to Maven, rather I was soliciting insight
> from the Maven community because I value their inventiveness.
>
> I am half way toying with the idea of building something myself, but
> first I want to make sure I am not reinventing the wheel.
Sounds like you have some good ideas. I'd check to make sure Puppet
and Chef don't have some recipes you could build on top of to help you
down this path before doing any building from scratch. We use puppet @
work pretty extensively but mostly on the sysadmin side and less on
the middleware/apps side - we are not a devops shop.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Deployment
Posted by Eric Kolotyluk <er...@gmail.com>.
I was not thinking of adding to Maven, rather I was soliciting insight
from the Maven community because I value their inventiveness.
I am half way toying with the idea of building something myself, but
first I want to make sure I am not reinventing the wheel.
I have been toying with the idea for a while as a software developer who
has had to build installers for applications and services, and I am
often dissatisfied with the experience I get using other people's
installers. At one time I was playing with the idea of my own installer
that would be cross platform, but the initial bootstrap would be
platform dependent, and install enough platform independent stuff, to do
the rest in a standard way.
For example, a couple years ago I built an installer for a service I was
working on. It is a very simple .NET Setup.exe, single file executable.
The first thing it does is make sure there is a JVM present, and
installs one if there is not. The next thing is does is creates a
Windows Service. The Windows Service is very simple, it uses jni4net and
starts up a file called service.jar, which then completed the rest of
the installation. The whole thing used fat binaries so it worked on a
variety of Windows platforms, both 32-bit and 64-bit. For OSX and Linux
I had intended a similar simple executable, that in turn launched the
same service.jar.
The part I was not too happy with was my service.jar was this ginormous
uber-jar created with the Assembly plug-in. Sure, everything worked
perfectly well, and was simple, but when I say ginormous I am very
serious. If I had had the time, the next thing I was going to do was
have my installer install Maven, and then bootstrap the rest of the
pieces by just choosing the right artifact names and versions given the
system environment I found. Basically, replace the uber-jar with a
common system-wide repository of jars, and configure the classpath
appropriately.
I am just thinking out loud and trying to get ideas from people.
Cheers, Eric
On 2013-03-01 5:31 PM, Ron Wheeler wrote:
> My feeling is that this would be a major addition to Maven and would
> still be missing a lot of stuff.
> It looks more like a CMS with some rules and some processes that
> construct a zip or an installer.
> You need a lot of flexibility in defining how assets are assembled
> into the required artifact.
>
> Of course, one could extend Maven but it would almost be a complete
> rewrite.
>
> I think that we would be better served by looking at what Maven does
> well and specifying a downstream process that incorporates the ideas
> that you identified below but into a system that focuses on deployment.
>
> It probably will attract a different type of person to the project.
> I would expect that the Maven team is heavily weighted towards
> developers as committers.
>
> The design and implementation of this new facility should be driven by
> system administrators and infrastructure support types who spend their
> days making applications run in production.
>
>
> Ron
>
>
>
>
>
> On 01/03/2013 8:06 PM, Eric Kolotyluk wrote:
>> Thanks for the pointers Stephen,...
>>
>> http://wiki.opscode.com/display/chef/Chef+Basics
>>
>> https://puppetlabs.com/puppet/what-is-puppet/
>>
>> Ron,...
>>
>> Yes, I remember that deployment was outside the scope of Maven, but
>> one of the things I like about Maven is the repository concept. I was
>> advocating extending this concept from the development realm to the
>> deployment realm sort of the way Microsoft's Global Assembly Cache
>> (GAC) works, but for open-source artifacts. In particular, we could
>> leverage existing technology and tools such as Maven, Nexus, Maven
>> Central, etc.
>>
>> For example, in terms of bootstrapping, you might have a simple
>> open-source installer the checks to see if there exists a local
>> system or network GAR (Global Artifact Repository), and if not,
>> creates one. Then it follows an embedded script, or remote script via
>> URI, to start populating the GAR with the artifacts needed. Finally,
>> when it starts deploying actual applications and services, it can
>> simply build a classpath by referencing locations in the GAR.
>>
>> I was installing Akka recently, and it seemed to be doing something
>> similar to what I was looking for. There was a small bootstrap
>> installers, that just kept pulling more and more stuff in.
>>
>> I have a project that is Maven based, and every time I setup my
>> development environment on a new system, I am simply amazed while I
>> watch Maven download hundreds of artifacts, and then it just builds
>> my project. I would like to have this kind of awesome experience in
>> production deployment tools.
>>
>> Cheers, Eric
>>
>> On 2013-03-01 2:07 PM, Ron Wheeler wrote:
>>> On 01/03/2013 4:26 PM, Eric Kolotyluk wrote:
>>>> A while back we had some interesting discussions on using Maven, or
>>>> maven-like technology for deploying production software. I was
>>>> wondering if
>>>> anything new has been happening since then.
>>>>
>>>> Basically what I am hoping to see is a generic installer framework
>>>> that
>>>> bootstraps deployment of a production system or service the way Maven
>>>> bootstraps a development environment.
>>>>
>>>> Can anyone point me to anything happening on that front?
>>>>
>>>> Cheers, Eric
>>>>
>>> My recollection of the conversation is that deployment is outside
>>> the scope of Maven and there are other tools that approach this from
>>> a more effective base functionality.
>>> Maven works best at giving you 1 artifact for a project whereas
>>> deployment needs to be able to generate a whole set of artifacts
>>> based on configurations that include
>>> - software artifacts
>>> - configuration files
>>> - branding
>>> - documentation
>>> - release notes
>>> - license agreements
>>> - installer
>>> each of which may have to be customized for each client or each
>>> deployment architecture(OS, database, etc.) or each deployment
>>> environment(production, test, QA) .
>>>
>>>
>>> Ron
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Deployment
Posted by Ron Wheeler <rw...@artifact-software.com>.
My feeling is that this would be a major addition to Maven and would
still be missing a lot of stuff.
It looks more like a CMS with some rules and some processes that
construct a zip or an installer.
You need a lot of flexibility in defining how assets are assembled into
the required artifact.
Of course, one could extend Maven but it would almost be a complete rewrite.
I think that we would be better served by looking at what Maven does
well and specifying a downstream process that incorporates the ideas
that you identified below but into a system that focuses on deployment.
It probably will attract a different type of person to the project.
I would expect that the Maven team is heavily weighted towards
developers as committers.
The design and implementation of this new facility should be driven by
system administrators and infrastructure support types who spend their
days making applications run in production.
Ron
On 01/03/2013 8:06 PM, Eric Kolotyluk wrote:
> Thanks for the pointers Stephen,...
>
> http://wiki.opscode.com/display/chef/Chef+Basics
>
> https://puppetlabs.com/puppet/what-is-puppet/
>
> Ron,...
>
> Yes, I remember that deployment was outside the scope of Maven, but
> one of the things I like about Maven is the repository concept. I was
> advocating extending this concept from the development realm to the
> deployment realm sort of the way Microsoft's Global Assembly Cache
> (GAC) works, but for open-source artifacts. In particular, we could
> leverage existing technology and tools such as Maven, Nexus, Maven
> Central, etc.
>
> For example, in terms of bootstrapping, you might have a simple
> open-source installer the checks to see if there exists a local system
> or network GAR (Global Artifact Repository), and if not, creates one.
> Then it follows an embedded script, or remote script via URI, to start
> populating the GAR with the artifacts needed. Finally, when it starts
> deploying actual applications and services, it can simply build a
> classpath by referencing locations in the GAR.
>
> I was installing Akka recently, and it seemed to be doing something
> similar to what I was looking for. There was a small bootstrap
> installers, that just kept pulling more and more stuff in.
>
> I have a project that is Maven based, and every time I setup my
> development environment on a new system, I am simply amazed while I
> watch Maven download hundreds of artifacts, and then it just builds my
> project. I would like to have this kind of awesome experience in
> production deployment tools.
>
> Cheers, Eric
>
> On 2013-03-01 2:07 PM, Ron Wheeler wrote:
>> On 01/03/2013 4:26 PM, Eric Kolotyluk wrote:
>>> A while back we had some interesting discussions on using Maven, or
>>> maven-like technology for deploying production software. I was
>>> wondering if
>>> anything new has been happening since then.
>>>
>>> Basically what I am hoping to see is a generic installer framework that
>>> bootstraps deployment of a production system or service the way Maven
>>> bootstraps a development environment.
>>>
>>> Can anyone point me to anything happening on that front?
>>>
>>> Cheers, Eric
>>>
>> My recollection of the conversation is that deployment is outside the
>> scope of Maven and there are other tools that approach this from a
>> more effective base functionality.
>> Maven works best at giving you 1 artifact for a project whereas
>> deployment needs to be able to generate a whole set of artifacts
>> based on configurations that include
>> - software artifacts
>> - configuration files
>> - branding
>> - documentation
>> - release notes
>> - license agreements
>> - installer
>> each of which may have to be customized for each client or each
>> deployment architecture(OS, database, etc.) or each deployment
>> environment(production, test, QA) .
>>
>>
>> Ron
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Deployment
Posted by Eric Kolotyluk <er...@gmail.com>.
Thanks for the pointers Stephen,...
http://wiki.opscode.com/display/chef/Chef+Basics
https://puppetlabs.com/puppet/what-is-puppet/
Ron,...
Yes, I remember that deployment was outside the scope of Maven, but one
of the things I like about Maven is the repository concept. I was
advocating extending this concept from the development realm to the
deployment realm sort of the way Microsoft's Global Assembly Cache (GAC)
works, but for open-source artifacts. In particular, we could leverage
existing technology and tools such as Maven, Nexus, Maven Central, etc.
For example, in terms of bootstrapping, you might have a simple
open-source installer the checks to see if there exists a local system
or network GAR (Global Artifact Repository), and if not, creates one.
Then it follows an embedded script, or remote script via URI, to start
populating the GAR with the artifacts needed. Finally, when it starts
deploying actual applications and services, it can simply build a
classpath by referencing locations in the GAR.
I was installing Akka recently, and it seemed to be doing something
similar to what I was looking for. There was a small bootstrap
installers, that just kept pulling more and more stuff in.
I have a project that is Maven based, and every time I setup my
development environment on a new system, I am simply amazed while I
watch Maven download hundreds of artifacts, and then it just builds my
project. I would like to have this kind of awesome experience in
production deployment tools.
Cheers, Eric
On 2013-03-01 2:07 PM, Ron Wheeler wrote:
> On 01/03/2013 4:26 PM, Eric Kolotyluk wrote:
>> A while back we had some interesting discussions on using Maven, or
>> maven-like technology for deploying production software. I was
>> wondering if
>> anything new has been happening since then.
>>
>> Basically what I am hoping to see is a generic installer framework that
>> bootstraps deployment of a production system or service the way Maven
>> bootstraps a development environment.
>>
>> Can anyone point me to anything happening on that front?
>>
>> Cheers, Eric
>>
> My recollection of the conversation is that deployment is outside the
> scope of Maven and there are other tools that approach this from a
> more effective base functionality.
> Maven works best at giving you 1 artifact for a project whereas
> deployment needs to be able to generate a whole set of artifacts based
> on configurations that include
> - software artifacts
> - configuration files
> - branding
> - documentation
> - release notes
> - license agreements
> - installer
> each of which may have to be customized for each client or each
> deployment architecture(OS, database, etc.) or each deployment
> environment(production, test, QA) .
>
>
> Ron
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Deployment
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 01/03/2013 4:26 PM, Eric Kolotyluk wrote:
> A while back we had some interesting discussions on using Maven, or
> maven-like technology for deploying production software. I was wondering if
> anything new has been happening since then.
>
> Basically what I am hoping to see is a generic installer framework that
> bootstraps deployment of a production system or service the way Maven
> bootstraps a development environment.
>
> Can anyone point me to anything happening on that front?
>
> Cheers, Eric
>
My recollection of the conversation is that deployment is outside the
scope of Maven and there are other tools that approach this from a more
effective base functionality.
Maven works best at giving you 1 artifact for a project whereas
deployment needs to be able to generate a whole set of artifacts based
on configurations that include
- software artifacts
- configuration files
- branding
- documentation
- release notes
- license agreements
- installer
each of which may have to be customized for each client or each
deployment architecture(OS, database, etc.) or each deployment
environment(production, test, QA) .
Ron
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Deployment
Posted by Graham Leggett <mi...@sharp.fm>.
On 01 Mar 2013, at 11:26 PM, Eric Kolotyluk <er...@gmail.com> wrote:
> A while back we had some interesting discussions on using Maven, or
> maven-like technology for deploying production software. I was wondering if
> anything new has been happening since then.
>
> Basically what I am hoping to see is a generic installer framework that
> bootstraps deployment of a production system or service the way Maven
> bootstraps a development environment.
>
> Can anyone point me to anything happening on that front?
For a number of years now I've been involved in packaging the configuration of systems over and above the code of systems in the native format of that system, for Redhat derivatives that would be RPM. In other words, you deploy code packaged as an RPM, as well as configuration packaged as an RPM, and then you add the last very small details (passwords, certificates) via chef/puppet.
Given that the majority of code we were building was built and released with maven, it was a natural extension that the configuration we were building was also built and released with maven, and so about a year ago I started getting the rpm-maven-plugin to build configuration RPMs.
This effort uncovered a number of maven bugs, the clean plugin was found to be incapable of deleting symbolic links (it now can), and maven-filtering component used by the resources plugin couldn't escape the "$" character used in shell scripts (now it can), and the rpm-maven-plugin had various other bugs (now fixed).
If you use the latest versions of the resources, clean and rpm plugins, building configuration packages as RPM works very well.
Using native packaging formats built by maven means that from an operations perspective, the software and the code "is just a package" and therefore something operations people are likely to be able to work with and understand, and at the same time the building and releasing of these packages "is just maven" and are therefore something developers are likely to be able to work with and understand.
In our environment, "deploy the production software" is just "yum install [production-software-config]". More importantly, "oh no, the upgrade broke everything" is responded to with "yum downgrade [production-software-previous-version]".
Using this technique should also be possible with other systems like Debian derivatives, you would need to choose a maven plugin able to create Debian packages, but the principle is the same.
Regards,
Graham
--