We'll respond shortly.
I've been working with my client, Unpakt, for a while now. One of their core values is making people's lives easier. They're specifically focused on making it easy for people moving to a new home or office to find a mover, compare prices and book their move online.
As a development team, we've taken that same core value of making things easier and applied it to our software development & deployment workflow. Over time, we've progressively improved our process. We're now at the point where we're happy with it, and I wanted to share what we've been up to.
Let's assume I'm using GitHub and Pivotal Tracker and I've just completed a story. What's next? Push my changes up to GitHub, click Finish on my story, wait for the build to go green, deploy to staging. Then, click Deliver on all the stories that have just been deployed. Other stories were most likely ready to be delivered as well, so I'll check that they were actually included in the deployment, and then Deliver them in Tracker.
The typical flow goes like this:
That's not really that bad. I'm lazy though. If something can be automated, I want it to be automated. For instance, the deployment process should be automatically handled by my Continuous Integration server.
If we take this to the next step and automate our build and deployments as described in Robbie Clutton's Building Confidence post, we can reduce that flow to this:
Let's assume we've done that. That's a nice improvement, as deploys will happen automatically whenever there's a green build. That in itself is amazing.
But, what if we could reduce the steps in my everyday flow to this?
I want that!
At Pivotal, our default choice for CI is Jenkins. I feel that Jenkins does a fine job running builds and reporting on a pass/fail. It also has nice plugins and plenty of features like build labeling and clustering.
JetBrains' TeamCity has all that, and more!
To be fair, TeamCity is missing some things that Jenkins has. However, I don't remember what they are because I've never used some of the deeper features of Jenkins. One thing TeamCity doesn't support well is running builds for multiple branches dynamically.
That said, I'm a huge fan of TeamCity. Here's why.
sh -c. RVM does weird things to your shell, and we've seen it exit the calling process unexpectedly. Do something like
sh -c "rvm exec gem install chef"to safely use RVM.
Schubert mentions that if
url_for is blowing up on you, you've got fundamental problems. Think of this as the canary in the coal-mine. For example, if you're trying to use namespaces in your rails controllers and there's a pluralization problem,
url_for will fail fast and hard.
Kris Hicks let us know about Git from the bottom up, a free book that looks to be a great read for Git beginners and not-so-beginners alike.
Kris also mentioned
/proc/[pid]/status, which is available on most Linux distros. It contains lots of useful information about any process, such as process state, memory sizes, etc. See PROC(5) for more.
Worst turnout so far this week... three of us did some neck rolls. Let's step it up tomorrow!
A standup of pivots (Sam Coward, Sean Moon, Peter Jaros, and Brent Wheeldon) have recently run into a bug in TeamCity that causes trouble with symlinks when using git.
If you commit symlinks into your repo, TeamCity will not properly transfer these to the build agents. They end up being copied over to the agents as plain text files.
The workaround for this issue is to use Agent-side Checkouts instead of Server-side Checkouts.
Mike Gehard mentioned that there is a movement to extract ActiveResource from Rails. For now, it's been shot down. But don't bet against the haters! Work is underway to rewrite it from scratch. We'll probably hear more about this as RailsConf proceeds.
Todd taught us a new stretch that involved us standing with one leg crossed over our other knee while bending and touching the floor. I always wonder what we must look like to innocent bystanders.
Beware setting class variables in Rails Initializers: Schubert warned us that if you're setting vars on your Rails classes inside of config/initializers, you'll see weird things happen in development mode.
If you set a class var on a model in an initializer, the value will be available on your first request to the app. However, upon the second request, Rails will reload the class, but it will not reload the initializers. At this point, you'll have lost the value.
Bash Brace Expansion: If you ever find yourself renaming a file in some faraway path, you think to yourself, "Wouldn't be nice if I didn't have to specify the entire path and filename twice?" Many shells provide you with a nice shortcut.
So, instead of:
mv /a/b/c/d/foo.feature /a/b/c/d/bar.feature
You can use:
It's pretty hot. Of course, there are many other applications of brace expansion. Check out the reference here: http://www.gnu.org/software/bash/manual/bashref.html#Brace-Expansion
Schubert rewired a bunch of power cables in the server room. If you notice that something isn't right, you now know who to blame.
Peter mentions that BarCamp NYC is this weekend, May 21, 22. It sounds like a lot of fun, and a great place to learn and meet interesting people.
Agile UX will be meeting here this Thursday. The topic will be Rails for UXers.
Finally, Austin lead us in stretches this morning. It was quite exhilarating. Most of us ripped our pants and snapped our credit cards in half.
If you're using a Continuous Integration tool, you should also be using an information radiator like Pivotal Labs' CiMonitor. CiMonitor is designed to be displayed on a screen that the entire team can see. If any of your builds go red, it shows up as a big red square and the team can quickly respond.
CiMonitor has long had support for CruiseControl.rb and Jenkins (formerly Hudson). However, my CI tool of choice is TeamCity from JetBrains. We've recently added native support in CiMonitor for displaying your TeamCity build status, and I want to show you how to get it going. It's as easy as configuring a new project and pointing to TeamCity's REST API. Let's walk through it step by step.