Вопрос

According to the documentation, RoundhousE has 3 modes:

  • Normal
  • DropCreate
  • RestoreRun

The first 2 are clear, but I don't understand RestoreRun Mode and the benefit it offers in Production:

Once you have gone to production, you switch from DropCreate to RestoreRun mode if your database is small enough. If not, you can continue with the idea of maintenance mode by switching to a new script name that you are making changes to. You can also backup the structure only (and some of the lookup data if you use a tool like LiteSpeed) and restore from that.

I was under the impression that RestoreRun would restore a backup of the database before running the migrations scripts. If this is the case, I could see it being useful in development where I am repeatedly testing my new scripts, but don't see the purpose of it for production.

Here are my questions:

  1. Am I misunderstanding the purpose of RestoreRun?
  2. What is an example scenario of how RestoreRun would benefit a production deployment?
  3. Are there any other differences other than starting with a db restore between RestoreRun and Normal mode?

Any insight into this would be much appreciated.

Это было полезно?

Решение

You misunderstood the documentation. It doesn't say to use RestoreRun on production. It says that you should use it during development when your db is already in production.

Другие советы

Ok, so I've found a few clues that confirms what it does, but I still don't understand why. I found this dialog between a user and the author of RoundhousE:

Q: Is RestoreRun the same as Normal except it performs a restore from backup first?

A: Yes, and it does not run items in the runAfterCreate folder either. It includes the /restore /restorefrompath=VALUE /restorecustomoptions=VALUE /restoretimeout=VALUE items. https://github.com/chucknorris/roundhouse/wiki/ConfigurationOptions

these must be new modes as I don't see them in rh.exe options with the version i have.

"\shared\MSBuild\Roundhouse\rh.exe" -w /restoretimeout 36000 /cs=%server.connectionstring% /f=%sql.files.directory% /vf=%version.file% /vx=%version.xpath% /r=%repository.path% /env=%environment%

This is equivalent to the Normal mode.

For production your going want something like above. Any new scripts you do not want run in production need to have ENV.%environment%.sql so that when the environment is set to production those scripts are not executed.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top