In the documentation, it is stated that Preview Environments create clone of the production environment database.
However, in this message it is stated that it is not currently supported and we are referred to a generic link to the initialDeployHook event:
Is there an example somewhere that would explain how to use that hook to seed the new preview database with current production data?
Thank you,
Jerome Tremblay
Hey Jerome,
The initialDeployHook (https://render.com/docs/preview-environments#preview-environment-initialization) can run any script that you provide.
Typically, we see customers seeding their database with test data as opposed to wanting a copy of production data - if you wanted to use production data you would have to perform a backup of the production database URL and then restore it into the preview environment database in your script. Your preview environment would need to have access to your production database URL to be able to perform a backup
I would also like to present a reason why you might not want to do this that you might want to consider.
By its very name, initialDeployHook runs after the first deployment of the service. Right now, there are 3 points in the build/deploy process where you can execute commands, these being:
buildCommand
startCommand
initialDeployHook
Taking each in turn, the buildCommand runs at the start of EVERY build process, this is where dependencies, asset compilation take place - and often, the best place to run migrations (presently).
startCommand is exactly that, the start command to get your service running and occurs after a successful build.
initialDeployHook runs once for every service’s lifetime, after the initial deployment has taken place.
So consider an application, let’s use Ruby on Rails as an example and we’re creating a preview environment - it needs to bundle gems, precompile assets, migrate the database and then start. Our example (https://render.com/docs/deploy-rails#create-a-build-script) has you bundle, precompile and migrate in the build command and then start the service. Employing an initialDeployHook as you are considering here with a dump/copy of your production database would replace your preview database with the production schema/data and essentially reset the migrations you’ve performed against the new database from the buildcommand. Once the backup/restore process is complete you’d then have to trigger a new migration (to reapply any migrations to the now production schema) as well as triggering a restart of your service so Rails can recache the DB schema. All of that is pretty long winded and in my own apps I simply do:
buildCommand: "./bin/render-build.sh" startCommand: "./bin/render-start.sh" initialDeployHook: "bundle exec rake db:seed"
And then, for my staging environment itself, I have a script that I manually run that takes a copy of the production database, anonymizes some data and then restores that into my staging db so that when my PRs are merged and deployed to staging they are using data that is closer to production.
One thing we do plan on addressing in the product is deployhooks to cover many more use cases, certainly a postDeploy that fires on every deployment so migrations that need to run all the time could be triggered but outside of the build process itself so all of this could become a lot more streamlined and simpler,
Does that help? Let me know and I can clarify anything further
Regards,
John B
Thank you very much for the explanations.
I will consider that and see what we can do. The manual script to backup and restore prod on demand might be a better alternative indeed.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.