Application deploymentt

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: Application deploymentt by JavaFan (Canon) on Feb 07, 2012 at 13:20 UTC
What is the best (and ideologicaly correct) way to deploy application dependencies. First question: deploy where? A set of machines you have total control over? Some machines internal to the company? All identical machines? Random machines worldwide running random OSses? Second question: deploy when? Automatically when a new version is available? Pushed on demand? Pulled on demand? Does it get rolled out one-machine at the time? All machines? Some machines? Third question: have you exhausted all ready made tools and solutions already available? Why aren't they working for you? My "best" way usually does not mean "not using what's already there".	[reply]
Re^2: Application deploymentt by Anonymous Monk on Feb 07, 2012 at 13:46 UTC
Servers. Different OSes CentOS/Gento/Debian. Later I plan to use same os everywhere if it will be possible. Yep, total control, internal company Deployment when needed. When new feature is ready it pulled to server from git repo. Rarely - tgz. Different branches can be rolled out separately. Also test deployments I have encountered two problems: raid failure on one of prod servers where we had no backup. So it was pretty slow and painfull to install all deps and get box running asap. Second - during fresh install one of deps had memory leak in version that was automatically fetched from cpan. Took some time to get it working.	[reply]
Re^3: Application deploymentt by JavaFan (Canon) on Feb 07, 2012 at 16:55 UTC
CentOS, Gento, Debian are all flavours of the same OS in my book. Anyway, I'd use puppet or cfengine or something similar to that. I have encountered two problems: raid failure on one of prod servers where we had no backup. So it was pretty slow and painfull to install all deps and get box running asap. What can I say? Incompetence? First of all, not having backups should, IMO, be a firing offense. No second chances. Second, you ought to be able to clone a new production box in a matter of minutes. Automatically. You should have an install server in your maintenance network that just dumps a complete OS tailored to your needs on a freshly booted box.	[reply]
Re^4: Application deploymentt by chrestomanci (Priest) on Feb 08, 2012 at 12:19 UTC
Re^3: Application deploymentt by InfiniteSilence (Curate) on Feb 07, 2012 at 14:08 UTC
...raid failure on one of prod servers where we had no backup... Ok, really? That isn't a problem with CPAN or modules. That is just being cheap and getting burned by it. ...during fresh install one of deps had memory leak in version... At first glance I thought this was the more legitimate reason to avoid using CPAN but then again, how do you know that any shared library you are upgrading to on a production system isn't going to bring about a similar problem? Celebrate Intellectual Diversity	[reply]
Re^4: Application deploymentt by Anonymous Monk on Feb 07, 2012 at 14:43 UTC
Re: Application deploymentt by chrestomanci (Priest) on Feb 07, 2012 at 16:19 UTC
When I have done this in the past, I experemented with CPAN and creating a localy built debian package that contained everything before deciding on local::lib and checking the local lib into source control. The developers on the project would run CPAN against the local lib whenever they needed to add new libaries, or update existing ones. Deployment on the servers was a simple svn checkout of the relevant tag. In the main it worked well, but there where occasions where perl packages that compiled binary XS code would break things quite comprehensively for other platforms, while appearing to work fine for the platform it was compiled an tested on. If you have more than one OS or processor archetecture on your servers then take a look at node 942112 where I have described the problem in more detail.	[reply]