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

  • Tgape (unregistered)

    This brings back memories. Several decades ago, I started at a new place of employment, and found that /usr/bin, /usr/local/bin, /etc, /usr/local/etc, and several other places that might be less anonymous had literally hundreds of files with datestamps, or '.bak', '.old', '.prior', '.somebodys_initials', and various combinations of those. There were only two people whose initials were represented, I'd only met one of those, and the other was far, far more common.

    They were not using any version control software, despite having at least one option already installed on the system, they were not using the system's installation process, nor were they using GNU install, which was also installed on the system as ginstall. They were not using a complicated bash script, however; this was before bash. I kid, it was totally after bash, but they were still using Bourne shell for their install process for some unknown and never really well explained reason.

    They were very definitely feeling the adverse effects of doing things the way they were doing them, but they were incredibly averse to change, because they were already having enough problems. And yet, demonstrating that there were fewer problems doing things my way did not motivate more than a couple people to change how they were doing things.

    To be clear, using a standard installer did not magically make all updates work correctly. However, it did mean that we had a rollback process that wasn't "Remember which extension we used for the backups this time and restore them. Except sometimes accidentally somehow restore one or two backup files with a different extension for no explained reason and then panic when things fail spectacularly because that was from a year ago and almost nothing matches up with anything."

Leave a comment on “Back Up for a Moment”

Log In or post as a guest

Replying to comment #682275:

Log Out

« Return to Article