Is this a good practice to use CommandLineRunner to setup app on the first deploy. For example, I want to:
Create user's roles in the DB;
Load admin's login and pass from property file and create admin-user (on user per app) in the DB.
Or can you advise a better variant for me?
I would not recommend doing it that way. Database setup, as well as future migrations, are handled nicely with either Flyway or Liquibase.
Related
I would like to know what would be the best guide to follow and things to consider if i would want to Add Migrations to a Project and note that the project:
is live (dev/staging/production environments)
Model of the live versions has changed and some fields/tables are
removed/added
is hosted with Azure App Service (Publish settings)
is an MVC project with Entity Framework 6 using code first
I know the basics of adding/using migrations but that's it.
I would like to know how i can implement migrations to my solution, publish the new project (changed model) without losing any data.
Is this possible and can anyone suggest me anything to look at that is well explained for this kind of setup?
EDIT
I am testing this on development but i can't make it work without having my database recreated, hence losing existing data...
My configuration file:
public Configuration()
{
AutomaticMigrationsEnabled = true; // tried false as well
ContextKey = "ContractCare.Models.ApplicationDbContext";
AutomaticMigrationDataLossAllowed = false;
}
Kind regards
Add an empty snapshot migration to your DEV environement. This will capture the current state of that model:
enable-migrations
Add-Migration InitialBaseline –IgnoreChanges // Tells EF not generate Up() code of existing objects
update-database
Now all subsequent changes in DEV can be deployed to other environments either by changing the connect string and re-running or by generating a script that can be run on those servers update-database -Script.
Before that, you have to "catch up" the other environments to the state of DEV using the processes you already have in place. Then you apply the InitialBaseline migration to those environments.
Moving forward you can apply the DEV migrations to UAT, STG and eventually PROD. Since a lot of migrations tend to happen in DEV, you can roll those up into a single migration as Chris explains here.
I'm having trouble finding a web interface in Heroku to write SQL queries that can be created by app collaborators. I want to be able to query from a computer that doesn't have the heroku toolbelt installed as a collaborator.
Currently, I've been using the dataclips feature to do such a task, however it only allows the query to be modified by the app owner.
I'm not sure if I'm just misunderstanding how Heroku Dataclips works or just can't find a feature that allows collaborators to do such a task?
Collaborators in your application can also modify dataclips. However data clips are intended to be a 'data clip' and not a webUI onto your database. Giving anyone the ability to update your application/data requires them to be a collaborator. Heroku provides no other security role than that.
I have been working with Laravel 3 on my local server. I have been using terminal and Artisan to perform my migrations.
I want to install my site on my production server, but I want to create a sort of 'install/migration' script that will perform all the migrations and guide a user through configuration.
I have found where all migration methods are (used by artisan) but I'm struggling to use them. Anyone know how?
I think you are confusing some things (I'm not sure, so I'll tell just in case).
Migrations are meant for developers. Your end users don't run migrations directly. So migrations are for you and your fellow developers. If you want your users to run migrations, than you just create a normal page and have some link or a button that the user presses and this will run an action (a function) on your controller (if you have routes set up this way). In this function, you should run the migration.
Running migrations from PHP: you can use the Command class to run tasks.
Command::run(array('migrate'));
This will run the migrate task, obviously.
Is this what you're after?
I have a running application in which client wants to implement BlogEngine, I have done almost but in the existing application there are also a registration, so now i want that when a user registration at my application that particular user be able to login in blogEngine.
I am using sql database and set all the settings in web.config.
Abhisheks, It sounds like you want to use the same user system as your existing web application. What you need to do is configure your authentication provider for BE.net to use the same user system as your existing app. You can either roll your own provider via code, or if your existing app is using the standard .net auth provider, then you should be able to just piggy-back off of that by configuring BE to use that via your web.config file.
Is it possible to create a new user in sonar without using the web interface?
I need to write a script that inserts the same users for some tools, including sonar.
There are three ways you can do this:
Write directly to the database (there is a simple table called users).
Use the LDAP plugin, if you specify sonar.authenticator.createUsers: true in sonar.properties, it will create the users in the sonar database automatically the first time they authenticate.
Write a java application that depends on the sonar plugin API, you can then use constructor injection to get a Sonar hibernate session and persist the user you want. See Here.
Since SonarQube version 3.6, there is support for user management in webservice API:
https://sonarqube.com/web_api/api/users
http://docs.sonarqube.org/display/DEV/Web+API
The web service API does not seem to support user management. Anything's possible, but it doesn't look like this is offered directly via Sonar.
You could probably use some web automation library (webbrowser, webunit, watir, twill) to do it through the running server; it might even be possible to just use something like 'curl' by looking carefully at the page source for the users/create form.
Or, if you want to go straight to the database, you could try to pull out the user creation functionality from the code and mess with the sonar.users table directly.
There is the LDAP Plugin, which would take care of authentication, but it still requires you to create the users in Sonar, so that wouldn't solve your problem.