Here’s some information from Engine Yard (our hosting service provider) about yesterday afternoon’s data center outage, which affected a number of applications including Pivotal Tracker:
http://blog.engineyard.com/2009/03/31/march-30th-outage
We apologize for the inconvenience this outage caused, and appreciate everyone’s patience. As detailed in Engine Yard’s post, steps are being taken to ensure that this does not happen again.
Desert::Manager.require_all_files added by Brian Takita which does eager loading.Compass author Chris Eppstein describes a new trend in the stylesheet framework world towards adhering to semantic markup and maintaining the separation between content and style. He shows how Compass and Sass can untangle stylesheets and allow reusable styles, classes, and designs without imposing on the markup.
“Overriding attributes in form helpers seem to be skipped, and the attributes in the database are used instead. Is there a reason this behavior makes sense?”
Adam will be submitting a patch that allows overriding of attributes. It as mentioned that the existing behavior might be useful in the error case of a pre-coerced form.
AutoTagger is a gem that helps you automatically create a date-stamped tag for each stage of your deployment, and deploy from the last tag from the previous environment.
Let’s say you have the following workflow:
You can use the autotag command to tag releases on your CI box, then use the capistrano tasks to auto-tag each release.
gem sources -a http://gems.github.com
sudo gem install zilkey-auto_tagger
To contribute, you can fork the github repository.
You can also visit the tracker project
Installing the gem creates an executable file named autotag, which takes two arguments: the stage, and optionally the path to the git repo:
$ autotag demo # => creates a tag like demo/200804041234 in the current directory
$ autotag demo . # => same as above
$ autotag demo /Users/me/foo # => cd's to /Users/me/foo before creating the tag
Running autotag does the following:
$ git fetch origin --tags
$ git tag <stage>/<timestamp>
$ git push origin --tags
AutoTagger comes with 2 capistrano tasks:
release_tagger:set_branch tries to set the branch to the last tag from the previous environment.release_tagger:create_tag runs autotag for the current stageExample config/deploy.rb file:
require 'release_tagger'
# The :stages variable is required
set :stages, [:ci, :staging, :production]
# The :working_directory variable is optional, and defaults to Dir.pwd
# :working_directory can be an absolute or relative path
set :working_directory, "../../"
task :production do
# In each of your environments that need auto-branch setting, you need to set :current_stage
set :current_stage, :production
end
task :staging do
# If you do not set current_stage, it will not auto-set your branch
# set :current_stage, :staging
end
# You need to add the before/ater callbacks yourself
before "deploy:update_code", "release_tagger:set_branch"
after "deploy", "release_tagger:create_tag"
Assume you have the following tags in your git repository:
The deployments would look like this:
cap staging deploy # => sets branch to ci/01
cap production deploy # => sets branch to staging/01
You can override with with the -Shead and -Stag options
cap staging deploy -Shead=true # => sets branch to master
cap staging deploy -Stag=staging/01 # => sets branch to staging/01
I have this working on a single project, and there is a fairly complete spec suite, but use at your own risk. It’s probably worth setting up on a demo project before adding it to a production repo.
Over time it would be nice to add other scms like subversion as well, so that you have a single way of tagging, regardless of scm.
Special thanks to Brian Takita, who gave me an initial implementation. Another useful link is http://codeintensity.blogspot.com/2008/06/changelogs-and-deployment-notification.html.
Happy tagging!
“What’s the best way to get gems for forked repos?”
There was quite a discussion on this. The specific issue is that the team is trying to use Compass (Chris Eppstein gave a talk on Compass at Pivotal on 3/18-look for the future video on our Talks Page.) For the moment, since compass depends on the edge version of sass you must first manually install sass before installing the compass gem.
As I’ve mentioned before, I’ll be giving a talk at RailsConf on how I “got more agile” once I was able to practice every day. The goal is for my story to help you in your career, telling some good stories in the process.
To celebrate/entice you to come to RailsConf & my talk, (Tuesday, 2:50pm, Ballroom A) and to thank those of you who contributed your own tips, I have two things for you.
First is a promise of Pivotal Labs swag (content TBD) to anyone who submitted a tip & to the first five comment authors who claim it below and identify themselves at the actual session – no sneaking off to Scott’s Advanced Git talk.
Second, for everyone, is a RailsConf discount of 15% in case you haven’t registered yet. When you register, use the promo code RC09FOS. Note that as of yesterday, the Hilton’s room rate has dropped to $99 a night. w00t!
“How do you test request headers? The request object is frozen…”
The team is using rspec to test an OAuth implementation and needs better access to the request object.
At Pivotal Labs we take Continuous Integration (CI) seriously. Every project has a dedicated machine that serves as a CI environment. Each checkin on the project causes a build to be kicked off. A “build” means checking out the code from scratch and running of all the project’s tests, which, for a Rails project, means unit and functional tests, JavaScript tests and Selenium tests. For the JavaScript and Selenium tests, we run multiple browsers on multiple OS’s (e.g. IE 7 on Windows XP, FF 3 on OS X, etc).
We consider it critically important to keep each project’s build green (i.e. successful) at all times. A build is the heartbeat of the project: if it’s green, everything is healthy; if it turns red (i.e. fails), the team is encouraged to jump on the problem and get it back to green right away. We want red builds to go away quickly; the longer a build stays red, the longer it takes to track down the problem and the more likely it is that additional tests will be broken (the “broken windows effect”).
In order to facilitate this level of discipline, we’ve learned over the years that making the status of our CI environments obvious and visible to the team is critical. If a team isn’t acutely aware of the status of its build, it’s unlikely that a red build will get noticed and fixed quickly. You can have the CI server email the team, but that doesn’t work very well when the whole team is pairing all day: it might be a few hours before someone notices the email. You can install plugins in your browser or system tray that show build status, which helps, but still, they’re not always obvious enough. The best way we’ve found to keep the team informed is to display the status of the build high on a wall near the team as a big red or green indicator. That way, even when you’re busy coding, it’s easy to notice the build going red. These days we use 2 wide screen TVs, positioned in the office so that one is easily seen from any developer station.
When there’s only a single project going on, we’ve found that a screen that’s simply all red or all green is effective. At Pivotal Labs, though, we have many projects going on at once. Rather than putting numerous TVs up on the wall, we’ve created an application that aggregates each project’s CI status into one page. It’s only visible internally, of course. It displays the build status of each of our projects – all the client projects, internal projects, and open source projects that Pivotal Labs is involved with.
Recently we decided to bring up an external instance of the aggregator that shows the status of our open source projects. We’ve also pulled in the status of some of the open source projects that Pivotal depends on (e.g. Rails, CCrb). It’s available at ci.pivotallabs.com. The idea is to provide the same level of visibility into build status for open source developers, or teams that rely on their products, as we have internally at Pivotal Labs. Feel free to display the page on a monitor/TV/projector in your office! It refreshes itself every 30 seconds.
If you have an open source project and you’d like us to run your build and display its status, or if you already have a build and you’d like us to add it to the page, there’s no charge – just let us know (email contact@pivotallabs.com).
Pivot Corey gave a brown-bag lunch talk titled “There is No Such Thing as a CSS Class” (slides and notes) where he describes establishing a project specific “CSS System.” This excellent presentation complements the “Consistent and Effective CSS” talk (video and live demo available) given by Pivots Corey, Ryan, and Chris.