[Camps-users] changes to devcamps

[Spencer Christensen]

Hi all,
   Lately I've been working on implementing camps here at Skullcandy.  We have a small team of developers and a huge number of projects and needed a better solution for doing development.  We aren't using camps just yet but will be "launching" it very soon, and everyone here can't wait.

   One thing I wanted to bring up to the list is the changes that we've made to the dev camps code and design and hopefully contribute back some/all of what we've done here.  There are a few pain points that we ran into with the current design of camps that didn't fit our needs which taken in total made us decide to change the underlying design of camps.

    First of all, let me describe what code and systems we use and wanted included in a camp.  We are a hybrid shop- php and python, with several other pieces in the mix.  We run three public sites, and each of those have different international versions.  So really it is like having 24 sites.  Plus, for one of our sites we use varnish with esi and need to include that in camps so we can code for esi correctly.  We are moving from mysql to postgres and need the ability to have both databases in a camp.  We also use Solr for site search and need to include that.  There are a few other things, but these are the big ones.

   Without going into detail about everything here in this email (which would end up being too long for anyone to read)- let me just high light what we've changed at the design level and I can give more detail in followup emails if people are interested.

   Essentially all camp scripts are camp related workflows- run this, then run that, then this, then that.  So I wrote a workflow engine Camp::Workflow which reads workflow definitions from a yaml file.  These definitions are just a listing of perl functions to execute in order.  Thus the scripts mkcamp, rmcamp, re, etc. just instantiate and run the workflow for mkcamp, rmcamp, re as appropriate.  Then extending/altering these workflows is as easy as editing that yaml file.  For new or customized perl functions, I put all of my functions into a new package called Camp::Custom which is loaded by the workflow engine.
   For managing all the different services (apache, varnish, nginx, mysql, postgres, solr) I created a new camp-services.yaml file which defines each service and defines four commands for each service: create, start, stop, remove.  I can then call these commands directly from a workflow as needed.  This allowed me to abstract control over these services, which I needed because I have a second host that some of these services run on and need to ssh over to the other host to run commands.  And now all I need to do is edit the camp-services.yaml file to tell it if the service lives locally or on a remote machine and what the shell command is to run.

   That is the high level summary.  I'm hoping that all of our developers are going to be really using this new camp system in our next sprint.  Then I'll be able to know how well it is working for everyone.

   Comments/questions always welcome.  Thanks.


SPENCERCHRISTENSEN
SENIOR SYSTEMS ARCHITECT
SKULLCANDY
SCHRISTENSEN at SKULLCANDY.COM<mailto:LACKLEY at SKULLCANDY.COM>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mail.endcrypt.com/pipermail/camps-users/attachments/20120409/a8a329d3/attachment.html