4 ms·

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

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 https://devcenter.heroku.com/articles/releases). I can't wait for Flynn (http://flynn.io/ 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.

patio11 13y ago
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.)
- sjtgraham 13y ago
  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.
  - Sujan 13y ago
    > 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.
    - sjtgraham 13y ago
      Times are in the git log. Same as the commit message/tag name/etc.
      - mynameisvlad 13y ago
        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.
        Dylan16807 13y ago
        Personally I find git log easier to handle than an enormous list of tags.
  - Poiesis 13y ago
    "Good judgement comes from experience; experience comes from bad judgement."
- drags 13y ago
  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.
bradleyland 13y ago
> 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.
- FooBarWidget 13y ago
  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.
conatus 13y ago
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.

patio11 13y ago

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.)

sjtgraham 13y ago
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.
- Sujan 13y ago
  > 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.
  - sjtgraham 13y ago
    Times are in the git log. Same as the commit message/tag name/etc.
    - mynameisvlad 13y ago
      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.
      - Dylan16807 13y ago
        Personally I find git log easier to handle than an enormous list of tags.
- Poiesis 13y ago
  "Good judgement comes from experience; experience comes from bad judgement."
drags 13y ago
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.

bradleyland 13y ago

> 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.

FooBarWidget 13y ago
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.

conatus 13y ago

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.