Hacker News Reader

Comment by sjtgraham | Hacker News Reader

Capistrano, what a Byzantine way to deploy software; I haven't typed cap deploy in about 3 years. Heroku's model of Git-based deployment and 12-factor apps has never given me a problem. Also Heroku deploys are de facto tagged as Releases (https://devcenter.heroku.com/articles/releases). I can't wait for Flynn (http://flynn.io/) to be released, it provides a Heroku-esque Git-based deployment strategy on any host.

P.S. I enjoy reading your comments as do many others, but I feel you hand-wave over important points sometimes, e.g. Why you feel tagging is important. If it truly is a 500 word discussion it shouldn't be hard to synopsise.

View on HN

It is tangential to the point of the comment, since this only gets you to 0.001% of a Rails deployment which works, but if you're interested:

Tags, plus sufficiently advanced dependency management and database migrations (n.b. not trivial!), allow you to track and reproduce past states of the deployed software.

For example: A customer reports a problem. You verify the problem exists. The customer reports that the system didn't have the problem last week Tuesday. If you want to know why, tagged releases (and a record of them -- incidentally, another one of the 643 things to know is "All deploys should be recorded somewhere") let you travel in time back to the software in use last Tuesday, verify if the customer's recollection is accurate (well, sorta), and then compare just what has changed rather than trying to run down the bug without any historical context.

Naming things also lets you talk about them, which is helpful, because you'll want to talk about individual releases of the software. (I mean, sure, you could use random hexadecimal numbers, but for whatever reason people find production_release_20131007_3 a bit more informative than 066630de00d242137efab6bf21b8ea04aeee7a1d. One glance at the first one tells you that it's the 3rd deploy from October 7th, assuming you've used the company's naming convention for more than a minute. The second one tells you nothing and is difficult to pull useful information out of without having to manually cross-tabulate it with you git repository, which would be unfortunate if it were e.g. attached to a log file, customer support request, or Wiki article about known-good releases for interacting with external systems.)

Thanks it's not for my benefit, it's for the engineers that might not know better and blindly follow something you say because of your standing in this community. Cargo-culting is not a good habit to encourage in software engineering.

FWIW dates in tags are redundant because the tag itself has a time stamp. Re: environment names in tags, IMO they don't belong in the repo.

Thanks for replying.

> FWIW dates in tags are redundant because the tag itself has a time stamp.

Having them in the tagname makes it much easier and more visible.

Times are in the git log. Same as the commit message/tag name/etc.

It's still much easier to scroll down a list of tags and find the right one by date than to look through the git log and look at both a tag name and timestamp.

Personally I find git log easier to handle than an enormous list of tags.

"Good judgement comes from experience; experience comes from bad judgement."

This is where triggering deploys through Jenkins is really helpful. Now you have a record of which SHA was deployed, when it was deployed and a copy of the console log for the deploy. Can't do much better than that.

  after "deploy:restart", "deploy:tag_release"

  desc 'Tag release'
  task :tag_release do
    `git checkout #{rails_env}`
    `git tag #{rails_env}_#{DateTime.now.strftime "%Y_%m_%d-%H_%M"}`
    `git push --tags`
    `git checkout master`
  end

Boom!

That's not going to match the release name that capistrano chose, right? Seems like you'd want to use latest_release or something.

Yeah, modify to taste. I only wanted to post some example code to show how easy it is to automate tagging.

My code won't be appropriate if you don't use master/staging/production branches, either.

We do the inverse. We tag first, then instruct Capistrano to grab the latest release (with a prompt). We have a release plan though, where software goes through QA before it's tagged. Only software ready for production gets a tag. Everything up to that point is done on a release branch.

    set :branch do
      default_tag = `git tag`.split("\n").last

      tag = Capistrano::CLI.ui.ask "Tag to deploy (make sure to push the tag first): [#{default_tag}] "
      tag = default_tag if tag.empty?
      tag
    end

Just use git flow for releases. For non-trivial deploys, you may want to check out teamcity.

> Capistrano, what a Byzantine way to deploy software...

Why would you come here to say that? Capistrano is one way to deploy software. Heroku's method is another. Neither is wrong.

This kind of thing is why author's of open source tools like Capistrano get burnt out and just want to run for the hills. Because people with no skin in the game have to come along and shoot their mouth off.

You're probably a really nice person, but when you do things like this, you hurt other people and you make yourself look like an asshole.

Well-said. Heroku-style deploys are not a replacement for Capistrano-style deploys, merely an alternative. Capistrano is a much lower-level tool. I use Capistrano also for general sysadmin tasks that comprise multiple servers.

Is it really Byzantine? Never ever had this thought. Once its setup, you just cap deploy - how is this much different from git push heroku? To do anything complex with PaaS stuff you still have to write code to setup the environment - likely no more than for cap.

Reply on news.ycombinator.com