• Jaloopa (unregistered)

    you have already done your frist release today

  • Darren (unregistered)

    I don't hate this. This is basically doing a retention policy on the number of backups they're keeping (except for when they're creating manual backups). It's probably not the most elegant way, but the code is pretty clear and easy to follow.

    If they were to put a build number as part of the filename then they'd have to find another way of managing them to avoid keeping a backup of every single build.

  • Hanzito (unregistered)

    The person that introduces a space in the backup directory path is in for a nice surprise.

  • (nodebb)

    Now, admittedly, I don't think a lot of folks want to do more than 9 releases in a given day, but there's no reason why they couldn't just keep trying until they find a good filename. Or even better, require each release to have an identifier (like the commit or build number or whatever) and then use that for the filenames.

    Or just add h:m:s to the timestamp in the file name.

  • (author) in reply to Darren

    As is, they're keeping 9 backups (potentially) for every day. So it doesn't really represent a meaningful retention policy, it just limits you to 3285 backups a year. Which sure, that should be enough for anybody, but honestly, if you're just having a script that deletes the backups from old days, your fine.

    Actually, as I think about this more, if you're doing a release that crosses a day boundary (you hit deploy at 2359, for example), I suspect this will blow up in interesting ways if a rollback happens.

  • Jason Stringify (unregistered)

    I always think that an exclamation mark on an error message is equivalent to adding "you idiot!" - as in "invalid entry!" - so having three here is like getting a punch in the face on top.

  • (nodebb)

    Someone was missing VAX/VMS.

  • Industrial Automation Engineer (unregistered)

    I wanted to comment, but I had to do it manually.

  • Darren (unregistered) in reply to Remy Porter

    Ah, yeah. Forgot that they were using the date as part of the backup filename. In which case, I do now kind of hate it...

  • (nodebb) in reply to Remy Porter

    Actually, as I think about this more, if you're doing a release that crosses a day boundary (you hit deploy at 2359, for example), I suspect this will blow up in interesting ways if a rollback happens.

    Not as interesting as they would be if the value of date was recalculated in every test...

  • Loren Pechtel (unregistered)

    They should be using a build number.

    But the loop most certainly needs to terminate somewhere. I have been the victim of one such loop that didn't terminate. Every 5 minutes the engine checks whether everybody's turn has been submitted in each game. If all moves are present, process the turn.

    All moves present, process the turn--failure, move version is higher than the game version, abort. Anticipated failure, but there was a slight bug and it didn't track that it had failed. Every 5 minutes. We all got hundreds of e-mails about it.

  • (nodebb)

    deployment is a series of complicated bash scripts doing complicated steps that can fail all the time

    That's what all deployment workflows start out as. It can then be migrated gradually to something better, a piece at a time, while still showing value to everyone along the way.

    Hahahah! Psych! It's never going to be migrated to anything. It's inevitably bound to be more of a metastatic cancer, ever growing and gradually killing its host (or at least making it very miserable).

  • Officer Johnny Holzopf (unregistered)

    Sadly, SOMETHING.COM;12, goo-voo values (G00V00), and GDGs have been invented decades ago, but elsewhere...

  • xtal256 (unregistered) in reply to Hanzito

    Hence why the common thinking amongst developers is that "spaces are bad" or "spaces cause problems". When really the problem is just laziness or stupidity.

  • Tinkle (unregistered)

    I love that the solution to the deployment script being complex and prone to breaking is to make the backup script complex. Lets hope that does not become prone to breaking.

  • John (unregistered)

    Uppercase in Bash ?

  • (nodebb) in reply to Tinkle

    I love that the solution to the deployment script being complex and prone to breaking is to make the backup script complex. Lets hope that does not become prone to breaking.

    complex + (complex × log(complex)²) = so simple ANY developer can do it?

  • löchlein deluxe (unregistered)

    Surely you can just have a Makefile (#!/bin/make -f and executable, accept no substitute) that calls logrotate? (And nevermind at least GNU's cp has a "make backups" flag.)

    Yes, I will leave a very distinct smell on my systems when I leave.

Leave a comment on “Back Up for a Moment”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article