The Power of Scripting: A Deploy Script

2.1 Refactoring Git deploy

We can make a small but important refinement to the script in Listing 1 by introducing an abstraction layer between the repository detection—in this case, detecting the presence of a .git directory—and the rest of our program. We can do this by defining a new method called git_repo?:

def git_repo?
  File.directory?(".git")
end

Here we’ve included a question mark ? at the end of git_repo? to follow the Ruby convention discussed in Section 2, in this case indicating that the method in question returns true if it is a Git repo and false if it isn’t.

Refactoring the code in Listing 1 slightly then gives the equivalent script shown in Listing 2.

#!/usr/bin/env ruby

# Returns true for a Git repository.
def git_repo?
  File.directory?(".git")
end

# Deploys a Git repository.
if git_repo?
  system "git push"
end

Note that the refactored script in Listing 2 is actually longer than the script in Listing 1. This is often the case when adding abstraction layers, but what we lose in brevity we gain in clarity. The meaning of

if git_repo?
  system "git push"
end

is immediately understandable in a way that

if File.directory?(".git")
  system "git push"
end

is not. Moreover, the benefit of adding abstraction layers compounds quickly, as we’ll see in Section 3.2.

3.1 Adding Jekyll sites and Softcover books

One of the easiest ways to determine a project type is looking for a directory characteristic of that project. We saw this with the .git directory in Section 2, and it works for other project types as well.

For example, every site built using the Jekyll static-site generator (covered in Learn Enough CSS & Layout to Be Dangerous and used to build this blog) has a directory called _site where the static site is stored. This means we can add a jekyll_site? method in analogy with git_repo? from Listing 2:

def jekyll_site?
  File.directory?("_site")
end

Similarly, Softcover books have a latex_styles directory, so we can define softcover_book? like this:

def softcover_book?
  File.directory?("latex_styles")
end

This suggests an augmented deploy script as shown in Listing 3. Note that services like GitHub Pages automatically build Jekyll sites, so in this case a simple git push is all that’s needed to deploy. As a result, we can combine Jekyll sites and plain Git repos into one step using the || (“or”) operator.

#!/usr/bin/env ruby

# Deploys a project.

# Returns true for a Softcover book.
def softcover_book?
  File.directory?("latex_styles")
end

# Returns true for a Jekyll site.
def jekyll?
  File.directory?("_site")
end

# Returns true for a Git repository.
def git_repo?
  File.directory?(".git")
end

# The main script.
if softcover_book?
  system "softcover deploy"
elsif jekyll? || git_repo?
  system "git push"
end

3.2 Completing the script

The final projects to support in our deploy script are Ruby gems and Ruby web apps (Rails⁴ or Sinatra⁵). For the first case, we’ll use the presence of the gemspec file needed by all Ruby gems, which we can test for as follows:

require "fileutils"
Dir["*.gemspec"].any?    # Returns true if any files end in ".gemspec"

The first line here is needed because, as noted briefly in Section 3, Dir is part of the FileUtils module in the Ruby Standard Library. This allows us to define a ruby_gem? boolean like this:

# Returns true for a Ruby gem.
def ruby_gem?
  Dir["*.gemspec"].any?
end

Finally, the trickiest test is for a Ruby web app. The complication is that most of the things characteristic of Ruby web apps are present in Jekyll projects and Ruby gems as well. For example, we could test for the presence of a file called Gemfile, but both Jekyll and Ruby gems have that, too. We could test for a test directory, but Ruby gems often have the same thing. But what does work is checking for both a Gemfile and (&&) a test directory but not (!) a Ruby gem:

# Returns true for a Ruby-based web app.
# Matches Rails and Sinatra apps.
def ruby_web_app?
  File.exist?("Gemfile") && File.directory?("test") && !ruby_gem?
end

Putting everything together gives the final deploy script shown in Listing 4. Making your way through this script is an excellent exercise in reading code (especially if you don’t already know Ruby!). Note that the use of abstraction layers (Section 2.1) means the main part of the script (at the bottom of the file) is readable even if you don’t understand all the implementation details.

#!/usr/bin/env ruby
require "fileutils"

# Deploys a project.

# Returns true for a Softcover book.
def softcover_book?
  File.directory?("latex_styles")
end

# Returns true for a Ruby gem.
def ruby_gem?
  Dir["*.gemspec"].any?
end

# Returns true for a Ruby-based web app.
# Matches Rails and Sinatra apps.
def ruby_web_app?
  File.exist?("Gemfile") && File.directory?("test") && !ruby_gem?
end

# Returns true for a Jekyll site.
def jekyll?
  File.directory?("_site")
end

# Returns true for a Git repository.
def git_repo?
  File.directory?(".git")
end

# The main script.
if softcover_book?
  system "softcover deploy"
elsif ruby_gem?
  system "rake release"
elsif ruby_web_app?
  system "git push heroku"
elsif jekyll? || git_repo?
  system "git push"
end

With the code in Listing 4, a simple

$ deploy

is all that’s required to deploy any of the project types supported by the script.⁶

The deploy script in Listing 4 is already quite useful. For my personal setup, I include a few refinements and extensions, including the following:

1. Include Rails or Sinatra apps that use RSpec for testing (which involves looking for a spec directory in addition to test).
2. Handle Jekyll sites that are built locally as well as those that are built on GitHub Pages (Box 1).
3. For all projects, automatically pull Git repos before pushing.
4. Automatically push Git repos for non-Git-only projects (e.g., do a git push before deploying a Rails app with git push heroku).

To implement 3 & 4, my standard deploy script includes a ship method as shown in Listing 5, which replaces the system command from Listing 4.

#!/usr/bin/env ruby
require "fileutils"

# Deploys a project.
.
.
.
# Ships a product.
def ship(command)
  pull = "git pull"
  push = "git push"
  full_command = command == push ? "#{pull} && #{command}" :
                                   "#{pull} && #{push} && #{command}"
  puts   full_command
  system full_command
end

# The main script.
if softcover_book?
  ship "softcover deploy"
elsif ruby_gem?
  ship "rake release"
elsif ruby_web_app?
  ship "git push heroku"
elsif jekyll? || git_repo?
  ship "git push"
end

With the ideas in this post (and maybe the Learn Enough All Access subscription), you’ll be in a good position to add these enhancements to your own version, as well as to write and extend utility scripts of your own. Good luck!