Timeline for Entity Framework - Is there a safety mechanism to prevent accidentally running Update-Database?
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 24 at 8:10 | comment | added | Arseni Mourzenko | Anyway, think of the script as an alias, nothing more. The goal being purely in terms of design and user interaction, by making production versus non-production visually distinctive (through red console background, for instance), and by requiring an extra effort from the user to run the production script, compared to the non-production one. | |
| Jul 24 at 8:08 | comment | added | Arseni Mourzenko |
@jpmc26: I imagine that we don't understand each other. In my answer, I was suggesting to just move the command dotnet ef database update into a script. Nothing else. Not putting credentials there. Anything like that. I haven't used the command myself, so I'm unsure whether it would ask the user for credentials during its execution (in which case it would continue to do so when executed from a script that in turn is ran by the user), or if it would use integrated security (in which case it would still do the same from script). And yes, the script would be in version control.
|
|
| Jul 24 at 4:07 | comment | added | jpmc26 | Hoarding code is a practice that has rightly gone by the wayside. Scripts don't only save time manually performing operations; they also serve as valuable process documentation. If you're going to spend company time writing a script, it should be shared. And code sharing outside of source control is an equally horrible idea; I assume I don't need to expound on why. So the reason I assumed the script would go into the repo is that I gave you the benefit of the doubt that you weren't advocating for other even worse practices. Was I wrong? | |
| Jul 23 at 7:24 | comment | added | Arseni Mourzenko | @jpmc26: what makes you think that by moving a command from the command prompt to a batch script, somehow, something would appear in your repository? | |
| Jul 23 at 7:17 | comment | added | jpmc26 | How is having production configuration in the repo used by an env specific script the same as not having it in the repo and not having an env specific script? | |
| Jul 23 at 7:05 | comment | added | Arseni Mourzenko |
@jpmc26: the variables thing is exactly the same, whenever you run dotnet ef database update directly or through a script.
|
|
| Jul 23 at 6:15 | comment | added | jpmc26 |
"Instead of dotnet ef database update, one should run ./deploy-to-local and ./some-complicated-path/deploy-to-production." This is a horrible suggestion. The variables specifying the production database (such as server and credentials) should not even be in the repository, even if your team is small enough that the developers are also doing deployment. They should read from environment variables, and whoever is deploying to prod should need to go look them up and set them in the shell before executing. And the deployment process should deploy using the same scripts for consistency.
|
|
| Jul 22 at 17:32 | history | edited | Arseni Mourzenko | CC BY-SA 4.0 |
added 225 characters in body
|
| Jul 22 at 17:26 | history | answered | Arseni Mourzenko | CC BY-SA 4.0 |