Permalink
Browse files

Cleaned up some of the wording.

  • Loading branch information...
1 parent c747827 commit 45d042c391a93456daa43a7f63599e8a8fa4f88b @xlson committed Apr 25, 2012
Showing with 18 additions and 17 deletions.
  1. +18 −17 _posts/2012-04-25-deploying-minecraftnet-in-14-minutes.md
@@ -7,7 +7,7 @@ published: false
{{ page.title }}
================
-Every time we deployed Minecraft.net it would take approximately 14
+Every time we deployed Minecraft.net it would take ~ 14
minutes, that's a lot of time. During that time I would either do
nothing or get started on something else, losing focus and probably
missing any potential problems with the deploy.
@@ -17,15 +17,15 @@ the deployment times was easy to remove from the equation.
## Reasons for our slow deploy
-1. Uploading files from the Mojang office to Amazon EC2 in America
+1. Uploading files from the Mojang office in Sweden to Amazon EC2 in America
2. Each server downloads its own dependencies
## 1. Location
Our build and deploy server was located in the office and was the culprit
-responsible for the first problem. Setting up a fresh Jenkins &
-Rundeck in the cloud was easy enough and fixed the problem for
+responsible for the first problem. Setting up a fresh [Jenkins](http://jenkins-ci.org/) &
+[Rundeck](http://rundeck.org/) in the cloud was easy enough and fixed the problem for
us, bringing down the deployment times to more sensible levels just by
putting the servers closer to eachother. I'd say this probably took
down the deployment times to 3 minutes or so, which is almost 5 times
@@ -37,9 +37,9 @@ It's not that I wasn't happy with our new deployment times, but the second probl
sense more important. Each server was running the dependencies task of
play (Play Framework) at application startup, fetching its dependencies
and relinkling modules to where they were located on disk. This meant
-startup took a bit longer than strictly necessary (and deploys as
-well) but more importantly, it meant that the dependencies
-theoretically could change when the application was restarted.
+startup took a bit longer than strictly necessary, which in turn
+affected deployment times. More importantly, it meant that there was a
+risk that the libraries we used would change between application restarts.
A deploy should send out a self contained distribution to the server
in question, anything else opens up the risk for unexplained problems
@@ -57,26 +57,27 @@ modules with the location on disk where play itself is located,
something that might differ from server to server.
I fixed this by packaging the modules with the distribution and adding a
-few extra lines to the start-script that would relink the module files
- on server startup, compared to the ~20 seconds it took to run
-the dependencies command on each server this now takes no time at
-all. This took the deployment time down to ~1 minute.
+few extra lines to the start-script that would relink the module
+reference files to the once packaged with the distribution on
+application startup. This removed the ~20 seconds per server it took to run
+the dependencies command and pushed the deployment time down to ~1 minute.
## Benefits and cost
It took me 2 days to do this, which is ~960 minutes (8 * 2 * 60). We do roughly 10 deploys each
week, perhaps even more now that they are quicker. This means we'll
save roughly 130 minutes ((14-1) * 10) each week, or 585 minutes
-(130 * 4.5) in a month. Given this we can see that the time saved will
-be more than the time spent on this improvement in less than 2 months.
+(130 * 4.5) in a month. Given this we can see that the time spent on
+making the deploys faster will be recuperated in less than 2 months.
More importantly, I can now do deploys more lightheartedly as I know
-it will only take a short period of my my time. I can send out quick
-fixes and features should no longer pile up for a big deploy at the
-end of the week. Making deploys go faster might change the way I work
+it will only take a short period of my my time. Deploying even the
+smallest of change becomes a no-brainer and features should no longer
+pile up into a big and scary deploy at the end of the sprint. Making deploys go faster might change the way I work
and that's the real advantage here.
Thanks goes out to my former collegaue Daniel Brolund who talked to me
about [team
minutes](http://danielbrolund.wordpress.com/2007/08/12/how-much-is-a-team-minute/)
-and the way making something fast might affect bevaiour.
+and the way making something faster might affect more than the time
+spent on doing the task itself.

0 comments on commit 45d042c

Please sign in to comment.