<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Engineering Rapleaf &#187; tools</title>
	<atom:link href="http://blog.rapleaf.com/dev/tag/tools/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.rapleaf.com/dev</link>
	<description>For engineers, by engineers.</description>
	<lastBuildDate>Mon, 12 Dec 2011 08:57:30 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
		<item>
		<title>Application Deployment at Rapleaf</title>
		<link>http://blog.rapleaf.com/dev/2010/05/25/application-deployment/</link>
		<comments>http://blog.rapleaf.com/dev/2010/05/25/application-deployment/#comments</comments>
		<pubDate>Tue, 25 May 2010 22:05:18 +0000</pubDate>
		<dc:creator>ckline</dc:creator>
				<category><![CDATA[Operations]]></category>
		<category><![CDATA[Capistrano]]></category>
		<category><![CDATA[CruiseControl]]></category>
		<category><![CDATA[Deploy]]></category>
		<category><![CDATA[Jabber]]></category>
		<category><![CDATA[openfire]]></category>
		<category><![CDATA[Screen]]></category>
		<category><![CDATA[sysadmin]]></category>
		<category><![CDATA[tools]]></category>

		<guid isPermaLink="false">http://blog.rapleaf.com/dev/?p=513</guid>
		<description><![CDATA[One challenge we constantly face at Rapleaf is how to remain agile as we grow. In the early days, we would say &#8220;I&#8217;m going to deploy&#8221; to a handful of other engineers in the room. When we needed to move beyond that, we designed a deployment system with 3 key objectives: Remain agile. Engineers should [...]]]></description>
			<content:encoded><![CDATA[<p>One challenge we constantly face at Rapleaf is how to remain agile as we grow.  In the early days, we would say &#8220;I&#8217;m going to deploy&#8221; to a handful of other engineers in the room.  When we needed to move beyond that, we designed a deployment system with 3 key objectives:</p>
<ol><strong>Remain agile</strong>.  Engineers should be able to deploy as frequently as they need to.</ol>
<ol><strong>Communicate</strong>.  Other engineers should know when a deploy is about to happen and when it is finished.</ol>
<ol><strong>Must be robust</strong>.  Have access controls, prevent multiple deploys and check for common problems.</ol>
<p>We were able to create a simple deployment system using <a href="http://www.gnu.org/software/screen/">Screen</a>, <a href="http://cruisecontrolrb.thoughtworks.com/">CruiseControl</a>, <a href="http://www.capify.org">Capistrano</a> and <a href="http://www.igniterealtime.org/projects/openfire/index.jsp">Openfire</a> (Jabber).  Screen was an obvious choice when we considered all of our requirements.  Before screen, we all deployed from our local machines.  There were a couple of problems with this: many people could deploy at once and their environments could be different.  Using a shared screen on a single machine solved both of these problems.  Screen also has access controls, multiple windows and scrollback history.  We have a window for each application and our screenrc file looks something like this:</p>
<p>[cc lang="bash" tab_size="2"]<br />
shell -${SHELL}</p>
<p># Set status line<br />
caption always &#8220;%{B}%t deploy %{R}REMEMBER TO &#8216;svn up&#8217; %{B}%? @%u%?%? %{d}[%h]%?%=%D %M %d %C %A&#8221;</p>
<p># command usually invoked by C-a &#8221; would also be available as C-a space<br />
bind &#8216; &#8216; windowlist -b</p>
<p># Create a screen window per application<br />
screen -ln -t &#8220;app1&#8243; -h 5000 1<br />
screen -ln -t &#8220;app2&#8243; -h 5000 2</p>
<p># Allow multiple users to connect<br />
multiuser on</p>
<p># Engineers that can deploy<br />
acladd engineer1,engineer2<br />
[/cc]</p>
<p>CruiseControl is a great continuous integration tool.  We always specify a revision when we deploy, so we can easily check cruise to make sure that the revision has passed the test suite.</p>
<p>Capistrano is the basis for all of our application deploys, including java apps.  We identified several functions we wanted to perform in every deploy and put those into a common library.  Those common functions include: notifying a jabber conference room on start/finish, running a sanity check on revision being deployed and dealing with our load balancer.  Capistrano has many other nice features that we use, but I won&#8217;t go into that here.</p>
<p>We&#8217;ve been running this system for a while and really like it.  We were able to meet all of our objectives with a simple design and some great open-source tools.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.rapleaf.com/dev/2010/05/25/application-deployment/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

