Giters

chucknorris / roundhouse

RoundhousE is a Database Migration Utility for .NET using sql files and versioning based on source control

Home Page:http://projectroundhouse.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Shell scripts

majkinetor opened this issue · comments

commented

You should support running shell scripts as a part of migration for more complex scenarios.

commented

Thank you for your suggestion. Do you have any examples of concrete use-cases where you want shell scripts to be run in a special order together with your sql scripts?

commented
  • Create a backup before/after migration
  • Send migration metrics to metrics server
  • Create complex logic not easily achievable using SQL
  • Do some infrastructure work, for example, deploy managed DLLs onto Sql Server server which might be introduced in the migration.
  • Dynamic generation o SQL scripts, for example, obtain latest data via some other mean, for example REST service to obtain latest currencies and seed them into the database.
commented

I think this would be a great feature.
We already love RH for managing the deployment of our db scripts into numerous environments.
We also use a lot of scripts to manage our infrastructure in Azure.
This infrastructure can change and evolve over time and we may need to sometimes apply new (1 time) scripts.

commented

I'm not totally sure these kinds of script should be inside the RoundhousE world, though. Why would you need the RH semantics for such scripts? Couldn't this be another part of the release? I'm open to being convinced otherwise, by all means, but it is dependent on someone taking ownership of this feature, as my time is very limited, I'm afraid.

Do you have any suggestions as to how the feature should work? Should there be "drivers" for each external script type (e.g. PowerShell, bash, cmd, python, etc), should they all be dependent on the enviroment? Which context should they run in?

commented

I would make this as simple as possible.

PowerShell only (via it you can do all things you mention) with exactly the same triggers as with sql and yet are done only in context of migrations.

Why would you need the RH semantics for such scripts?

I already provided the reasons in the comment above. Many things are not possible with sql only.

as my time is very limited, I'm afraid.

Sure, in FOSS world this is absolutely normal.