search

theSteveMitchell / after_party

Automated post-deploy tasks for Ruby/Rails. Your deployment is the party. This is the after party
MIT License
241 stars 50 forks source link

Open to adding a pre-task? #25

Closed edk closed 5 years ago

edk commented 8 years ago

I'm investigating the use of this gem for some stuff at work. I love the name and the implementation of after_party so far. 👍

Are you open to expanding the scope of the gem to include pre-tasks as well? If so, do you have any thoughts on the approach to take, or approaches you definitely don't want to see?

I've got a couple of initial ideas of how to approach this, but would love to get your input on any potential changes for a pre-party :)

Thanks!

theSteveMitchell commented 8 years ago

The goal of this gem is to help remove as many manual steps from deployment as possible, so I'm open to it.

The major complication would be that through Capistrano, the tasks run on the server. That means the code has to be there. When you create a pre-task, you can't run it until it's deployed to the server, unless we

  1. Run the task from he context of the deploying machine (which Capistrano has nice helpers for)
  2. Run the pre-task for the subsequent deployment, but not the first one.

Would love to hear your use case to better understand

edk commented 8 years ago

Thanks @theSteveMitchell , great question!

In my context I need to be able to handle no-downtime upgrades (we are using Capistrano). You are correct in that our setup will need to be updated to deploy the code, but not switch current to it on completion for the "pre-deploy" step.

Outside of the pre-deploy step, we currently have the ability to run database schema changes on-line (using mysql lock=none or pt-online-schema-change), and after_party has the tasks post-migration covered.

For the pre-case, we need the option of deploying the code, and running some sort of task before our on-line migrations run. Running from the context of the deploying machine isn't what I'm looking for.

So essentially, I need the ability to run arbitrary tasks before my migrations run, tracking completion to avoid re-running (with the option for running every time) and ideally keep it separated from after_tasks to make it easy to see what would run before migrations and what would run after the deploy finishes.

WDYT? Thanks!

theSteveMitchell commented 5 years ago

Hi @edk could you give an example in your use case of a task that you'd need to run before migrations? I'm wondering if that's something that should be added in the schema migrations themselves.

edk commented 5 years ago

sorry, it's been a while and i don't recall the details :) thanks, and it's great to see you back on the project 👍