Comments on: Building the high spires – enabling elastic cloud computing http://www.rhonabwy.com/wp/2009/03/29/building-the-high-spires-enabling-elastic-cloud-computing/ Mac, iOS, DevOps, and daily life in Seattle Fri, 25 Nov 2011 06:40:42 +0000 hourly 1 http://wordpress.org/?v=3.3 By: Andrew Carter http://www.rhonabwy.com/wp/2009/03/29/building-the-high-spires-enabling-elastic-cloud-computing/comment-page-1/#comment-92672 Andrew Carter Tue, 09 Jun 2009 06:55:08 +0000 http://www.rhonabwy.com/wp/?p=831#comment-92672 Count me in. I'm routinely working on these problems at work. None of the solutions out there seem to solve this well. Count me in. I’m routinely working on these problems at work. None of the solutions out there seem to solve this well.

]]> By: William Thompson http://www.rhonabwy.com/wp/2009/03/29/building-the-high-spires-enabling-elastic-cloud-computing/comment-page-1/#comment-90876 William Thompson Tue, 12 May 2009 04:16:27 +0000 http://www.rhonabwy.com/wp/?p=831#comment-90876 Perhaps it's not packages or a packaging format. Are you actually deploying packages or are you deploying virtualized servers. Why not have you build process output that. Snapshot and deploy. Anyway, won't work if you want to move the packages between servers, unless you want those moves as part of your build process. But you know what I mean, it's all about the granularity that you care about. Perhaps it’s not packages or a packaging format. Are you actually deploying packages or are you deploying virtualized servers. Why not have you build process output that. Snapshot and deploy.

Anyway, won’t work if you want to move the packages between servers, unless you want those moves as part of your build process. But you know what I mean, it’s all about the granularity that you care about.

]]> By: Rob Fahrni http://www.rhonabwy.com/wp/2009/03/29/building-the-high-spires-enabling-elastic-cloud-computing/comment-page-1/#comment-87842 Rob Fahrni Mon, 30 Mar 2009 00:18:26 +0000 http://www.rhonabwy.com/wp/?p=831#comment-87842 Joe, We had a real mess at work with our development teams a few of years back. Everybody was grabbing code from other groups, building it on their own boxes, and shipping their own "custom" builds. It was a real mess. In the end we needed a packaging scheme that would work on Linux and Windows so teams could package and release their components for use by other groups. It was decided to use RPM on Linux and INNO Setup on Windows (I would have picked MSI's, but INNO works quite well.) To describe dependencies YML was used. To parse and install the packages using the YML file a Perl script was written to download and install the packages, and a Ruby script was used to create the initial packages, using either RPM or INNO, depending on platform, again driven by a YML file. This has made the development process an absolute dream. I know it's not quite as polished as you're looking for, but it may point you in the right direction, and most of the technologies used are completely open. Joe,

We had a real mess at work with our development teams a few of years back. Everybody was grabbing code from other groups, building it on their own boxes, and shipping their own “custom” builds. It was a real mess.

In the end we needed a packaging scheme that would work on Linux and Windows so teams could package and release their components for use by other groups. It was decided to use RPM on Linux and INNO Setup on Windows (I would have picked MSI’s, but INNO works quite well.)

To describe dependencies YML was used. To parse and install the packages using the YML file a Perl script was written to download and install the packages, and a Ruby script was used to create the initial packages, using either RPM or INNO, depending on platform, again driven by a YML file.

This has made the development process an absolute dream.

I know it’s not quite as polished as you’re looking for, but it may point you in the right direction, and most of the technologies used are completely open.

]]>