31 ms·

This is great. Until you need to roll back.

brightball 5y ago
Keep a simple tool like Ansible around for those spooky admin tricks and you can take advantage of the Ansistrano plugins for smooth deploy and rollback (Ruby's great Capistrano tool ported to Ansible). https://ansistrano.com/ https://ansistrano.com/ It's pretty fantastic.
- 1MachineElf 5y ago
  This looks awesome. I'm currently in the middle of learning Ansible now for my FjeeBSD jails. Have any other plugins to recommend?
  - brightball 5y ago
    Anything by geerlingguy on Ansible Galaxy.
    - lenova 5y ago
      > Anything by geerlingguy on Ansible Galaxy. I've been writing some Ansible playbooks recently for the first time in years, and came upon geerlingguy's work. That guy is a powerhouse when it comes to writing Ansible roles/modules!
      - geerlingguy 5y ago
        Why, thanks ;)
thujlife 5y ago
rollback.sh
marcosdumay 5y ago
Why? Checkout what version you want to roll back to, and deploy it.
bkanber 5y ago
git checkout abcd1234 ./build.sh && ./deploy.sh I don't see the issue.
- dsgrillo 5y ago
  If you have any migration, you probably want to rollback them as well
  - mrweasel 5y ago
    That's sort of pet peeve of mine: Migration are done separate from code deploys. Version 1 of your code runs on schema version 1. Schema version 2 does not make chances that will break code version 1. Code version 2 can utilize the chances made in schema version 2, but you're still able to rollback the code. Each schema migration should also come with its own rollback script. The downside is that you might need three migrations for some operation, but at least you won't break stuff. The assumption that you can do a schema migration while deploying new code is only valid when you have very limited database sizes. I've seen Flyway migrations break so many times, because developers assumed it was fine to just do complicated migrations on a 200GB database. Or a Django database migration just lock up everything for hours because no one cared to think about the difference between migrating 100MB and 100GB. And I've never seen anyone seriously considering rolling back a Flyway migration.
    - spfzero 5y ago
      Agree with this and have practiced and advocated for it. Make the schema changes to support the new feature first, then verify existing software still works. Deploy the schema change. Then develop the new feature, test, and deploy the program. That way you can deploy and rollback without needing to synchronously run a bunch of migration routines.
qw 5y ago
I had a similar setup a couple of years ago, where I had to deploy without downtime. My solution was to simply have the old version running in parallel until I was certain the new version was ok ---------- Static website: 1. Setup NginX using a symlink to the current version 2. Copy the new files to a separate folder 3. Change the symlink to point to the new version ---------- REST service (behind NgninX reverse proxy): 1. Current version runs on port X. 2. Deploy new version and run it on port Y. 3. Update NginX config to use port Y and reload 4. If you need rollback, just reverse step 3. This can be done using scripts or Ansible too if necessary.

Keep a simple tool like Ansible around for those spooky admin tricks and you can take advantage of the Ansistrano plugins for smooth deploy and rollback (Ruby's great Capistrano tool ported to Ansible). https://ansistrano.com/ https://ansistrano.com/ It's pretty fantastic.

1MachineElf 5y ago
This looks awesome. I'm currently in the middle of learning Ansible now for my FjeeBSD jails. Have any other plugins to recommend?
- brightball 5y ago
  Anything by geerlingguy on Ansible Galaxy.
  - lenova 5y ago
    > Anything by geerlingguy on Ansible Galaxy. I've been writing some Ansible playbooks recently for the first time in years, and came upon geerlingguy's work. That guy is a powerhouse when it comes to writing Ansible roles/modules!
    - geerlingguy 5y ago
      Why, thanks ;)

thujlife 5y ago

rollback.sh

marcosdumay 5y ago

Why? Checkout what version you want to roll back to, and deploy it.

bkanber 5y ago

git checkout abcd1234 ./build.sh && ./deploy.sh I don't see the issue.

dsgrillo 5y ago
If you have any migration, you probably want to rollback them as well
- mrweasel 5y ago
  That's sort of pet peeve of mine: Migration are done separate from code deploys. Version 1 of your code runs on schema version 1. Schema version 2 does not make chances that will break code version 1. Code version 2 can utilize the chances made in schema version 2, but you're still able to rollback the code. Each schema migration should also come with its own rollback script. The downside is that you might need three migrations for some operation, but at least you won't break stuff. The assumption that you can do a schema migration while deploying new code is only valid when you have very limited database sizes. I've seen Flyway migrations break so many times, because developers assumed it was fine to just do complicated migrations on a 200GB database. Or a Django database migration just lock up everything for hours because no one cared to think about the difference between migrating 100MB and 100GB. And I've never seen anyone seriously considering rolling back a Flyway migration.
  - spfzero 5y ago
    Agree with this and have practiced and advocated for it. Make the schema changes to support the new feature first, then verify existing software still works. Deploy the schema change. Then develop the new feature, test, and deploy the program. That way you can deploy and rollback without needing to synchronously run a bunch of migration routines.

qw 5y ago

I had a similar setup a couple of years ago, where I had to deploy without downtime. My solution was to simply have the old version running in parallel until I was certain the new version was ok ---------- Static website: 1. Setup NginX using a symlink to the current version 2. Copy the new files to a separate folder 3. Change the symlink to point to the new version ---------- REST service (behind NgninX reverse proxy): 1. Current version runs on port X. 2. Deploy new version and run it on port Y. 3. Update NginX config to use port Y and reload 4. If you need rollback, just reverse step 3. This can be done using scripts or Ansible too if necessary.