Archive

Archive for December, 2011

Using watchr with PHPUnit

December 16, 2011 Leave a comment

I’ve known about watchr and autotest for a while but have never taken the time to set them up.  I should have done this a long time ago, I noticed the efficiency gains immediately.

Initial Setup

Create a local Gemfile and install the necessary gems.

jheth@box1:~$ cd ~/project/src/test/
jheth@box1:~/project/src/test$ cat - > Gemfile << EOF
source :rubygems
gem 'watchr'
gem 'rev'  # Provides event support for Linux
EOF
jheth@box1:~/project/src/test$ bundle install --path=vendor --binstubs

This will install the watchr gem into a local vendor folder and create ~/project/src/test/bin which will contain the watchr executable script.

Configure Script

Next, configure the watchr.rb script.  You can configure any number of watches for files and/or folders.  The watch() function takes a regex with any number of captures to grab filename or parts of the path. The ‘do’ block is executed whenever a file changes. You can change the phpunit parameters to whatever you want.

~/project/src/test/watchr.rb
# Watch test files
watch("src/test/model/(.*\.php)") do |md|
   system("cd src/test/model && phpunit --debug --colors '#{md[1]}'")
end
# Watch src objects
watch("src/main/model/(.*)\.php") do |md|
   system("cd src/test/model && phpunit --debug --colors '#{md[1]}Test.php'")
end

Notice that these paths are RELATIVE, which means you must run this script from ~/project.  I had trouble with both absolute and relative (../) style paths so I just decided to run it from a higher level folder.

cd ~/project && ./src/test/bin/watchr ./src/test/watchr.rb

To see what files are being watched you can use the -l argument. This only prints the names, it doesn’t actually begin watching.

./src/test/bin/watchr -l ./src/test/watchr.rb

Fire this up in a separate terminal and let it just sit there all day while you edit your files. You will see the phpunit output everytime you save a file. I turned on –colors and –debug so I don’t have to guess when something goes wrong.

Wrap Up

This has already saved me a ton of time since I would previously switch between terminal sessions, typing or arrowing to the phpunit command I wanted to run. Now I never have to leave the editor and when saving either the test or the underlying source file, the tests get run. Decreasing the amount of time between edits and test execution is a huge time saver. I get instant feedback every time I save.

The startup command is a bit annoying to type so I added an alias to my .bash_profile.  No matter where I am, I can just pick a terminal and type ‘watchem’ and I’m up and running.

alias watchem='cd ~/project/ && ./src/test/bin/watchr ./src/test/watchr.rb'
Categories: Uncategorized Tags: , ,

APT Packaging

December 11, 2011 Leave a comment

At Sentry we originally built a lot of our servers by hand, manually installing each OS and dependency we needed to support our various software products/services. This was a very tedious task for our sysadmins and one that was very error prone. We could never quite guarantee that a new server was exactly the same as the old server it was replacing (in terms of version dependencies). Many times we would run into issues because an admin forgot a configuration step or installed the wrong version of a dependency, causing us to scramble and fix things.

We finally wised up (a demand from our CIO) to package everything and use apt for installation.  This would allow us to specify all of our dependencies in writing and have an automated way of installing them on any server we wanted. This (obviously) has proved to be a huge success.

After a year of our sysadmins managing packages, I got pulled in to help build/support our software packages. I was pretty impressed by the setup our admins put together  and thought I’d share about that here.

Anatomy of a Package

A minimal apt package contains the following files. The control file is the heart of the package. It’s common to have the post/pre files for completeness even if they aren’t used.

rvm-sentry
   DEBIAN
      control
      postinst
      postrm
      preinst
      prerm

The control file specifies the package name, version, dependencies, author, and a description.

Package: rvm-sentry
Version: 0.12
Architecture: amd64
Priority: extra
Maintainer: jheth <jheth@sentryds.com>
Depends: debian-sentry, bash, curl, git-core, build-essential, bison, openssl, libreadline6, libreadline6-dev, zlib1g, zlib1g-dev, libssl-dev, libyaml-dev, libsqlite3-0, libsqlite3-dev, sqlite3, libxml2-dev, libxslt-dev, autoconf, libc6-dev
Description: Installs RVM as Sentry expects it

The other files (marked as executable) are often just shell scripts that get run according to their names.
– preinst is run prior to the installation of the package
– postinst is run after the installation of the package dependencies
– prerm is run prior to package removal
– postrm is run after the package dependencies have been removed

Our sysadmins created a few shell scripts to automate the creation and building of these packages.  Whenever a change is committed to one of our packages (currently SVN), a server side process picks up the change, rebuilds the package, and makes it available on our internal package server.

The only thing left to do is to tell our servers where to find the Sentry specific packages.  This is done by adding a .list file to /etc/apt/sources.list.d, which gets searched during apt-get install.

echo deb http://package-server/debian stable main > /etc/apt/sources.list.d/sentry-infra.list && apt-get update

All of this has taken the guess work out of building servers and gives us confidence that a server has what it needs to run our software on top of it. These package in conjunction with our GRID infrastructure has made building and deploying our products a breeze.

Categories: Uncategorized