Hi All,
I read many articles related to self provisioning system where application is capable of creting db assets on first deployment. I have slightly different views on this. Below are the reasons.
- Difficult to make changes without redeploying the code as there is tight coupling between code and assets needs to be created or modified.
- Permissions needs to be given to the system/super admin user that is running the application.
- As a repercussion of two if security of your deployed application is compromised than you may loose your DB.
- Most of the financial org. avoids this due to security aspects.
Overall, do read out on new options that are getting traction but do diligence on new features if it makes sense in the context that you are applying them.
Top comments (3)
This is a good point. It comes under seperation of concern and unwanted coupling between DB and Application
Flyway and Liquibase can be used for this purpose.
In Liquibase you can generate your SQL Script from comparing the diff from your code itself.
This is an excellent point. All security, for every system in the stack, should be as restricted as possible.
I mostly work on large scale SaaS applications. We never let our application code create or destroy database assets on deployment. Typically we commit db migration scripts with the code but run those migrations separate from the app deployments under a special user account.
True Matthew,
Most of the places this is hyped one size fits all kind of concepts.
I just saw this post on server side. Thought of sharing that it is not just wise to fall in because technology widget enable it.
theserverside.com/video/3-ways-to-...