Migrate database when deploying to Azure App Service
I'm using the ASP.NET Core & Angular startup template from ASP.NET Boilerplate with Multi-Tenancy disabled: 1 database with a single tenant(Default).
I'm also using TeamCity to build/test/publish the projects available in the startup template so I end up with 3 NuGet packages that are getting pushed to Octopus Deploy:
- API (Host project, ASP.NET Core Web Application)
- Migrator (Console application, capable of migrating the database(s))
- UI (Angular App)
I want to deploy this setup to Azure with Octopus Deploy(self hosted, v2018.9.0) in the following way using 2 App Services(Host & UI) and 1 Azure SQL database(Host):
- Take the UI and API applications offline, displaying a friendly maintenance message while updating the projects.
- Migrate the database using the Migrator package
- Deploy the API application package
- Deploy the UI application package
- Put the API application online, maybe some more tests to check that it's working correctly
- Put the UI application online.
If all this was on-prem, I would have no questions. It's the Azure part that I can't figure out because I don't know how to do these things on Azure via Octopus Deploy:
- Put an Azure App Service offline/online (using an app_offline.htm file)
- Deploy the Migrator package to the API Azure App Service in a special folder(so that I don't overwrite the API deployment) and run the migrator: dotnet [migrator.dll] -q
I tried using the Octopus Deploy "Deploy an Azure Web App" but this step won't let me also deploy the migrator package and run it before the API package is deployed. Or does it? I don't know how.
I tried using the "Run an Azure PowerShell script" but this executes on the Octopus Deploy server and not on the Azure App Service environment right?
Maybe there are other, even better, approaches deploying this setup to Azure?
azure aspnetboilerplate octopus-deploy asked Nov 14 '18 at 13:28
JorgJorg
84
add a comment |
I'm using the ASP.NET Core & Angular startup template from ASP.NET Boilerplate with Multi-Tenancy disabled: 1 database with a single tenant(Default).
I'm also using TeamCity to build/test/publish the projects available in the startup template so I end up with 3 NuGet packages that are getting pushed to Octopus Deploy:
- API (Host project, ASP.NET Core Web Application)
- Migrator (Console application, capable of migrating the database(s))
- UI (Angular App)
I want to deploy this setup to Azure with Octopus Deploy(self hosted, v2018.9.0) in the following way using 2 App Services(Host & UI) and 1 Azure SQL database(Host):
- Take the UI and API applications offline, displaying a friendly maintenance message while updating the projects.
- Migrate the database using the Migrator package
- Deploy the API application package
- Deploy the UI application package
- Put the API application online, maybe some more tests to check that it's working correctly
- Put the UI application online.
If all this was on-prem, I would have no questions. It's the Azure part that I can't figure out because I don't know how to do these things on Azure via Octopus Deploy:
- Put an Azure App Service offline/online (using an app_offline.htm file)
- Deploy the Migrator package to the API Azure App Service in a special folder(so that I don't overwrite the API deployment) and run the migrator: dotnet [migrator.dll] -q
I tried using the Octopus Deploy "Deploy an Azure Web App" but this step won't let me also deploy the migrator package and run it before the API package is deployed. Or does it? I don't know how.
I tried using the "Run an Azure PowerShell script" but this executes on the Octopus Deploy server and not on the Azure App Service environment right?
Maybe there are other, even better, approaches deploying this setup to Azure?
azure aspnetboilerplate octopus-deploy asked Nov 14 '18 at 13:28
JorgJorg
84
Are you trying to make simple schema updates to your database while keeping the data or are you bringing a whole new db? Are you going offline by choice because with App Services you could deploy and update without ever going offline.
– Simon Bourdeau
Nov 14 '18 at 21:18
Simple schema changes, it's EF Core using migrations. When I update the database(before the API is updated), it can cause issues with the API project not updated yet right? E.g. column renames etc. As I understand when deploying a new version of a Web App it's a new instance right? So no need to go offline indeed if the schema changes are backwards compatible, but what if they aren't?
– Jorg
Nov 15 '18 at 7:52
As a rule of thumb I don't make schema changes that are not backwards compatible on a production load db.
– Simon Bourdeau
Nov 15 '18 at 18:54
add a comment |
I'm using the ASP.NET Core & Angular startup template from ASP.NET Boilerplate with Multi-Tenancy disabled: 1 database with a single tenant(Default).
I'm also using TeamCity to build/test/publish the projects available in the startup template so I end up with 3 NuGet packages that are getting pushed to Octopus Deploy:
- API (Host project, ASP.NET Core Web Application)
- Migrator (Console application, capable of migrating the database(s))
- UI (Angular App)
I want to deploy this setup to Azure with Octopus Deploy(self hosted, v2018.9.0) in the following way using 2 App Services(Host & UI) and 1 Azure SQL database(Host):
- Take the UI and API applications offline, displaying a friendly maintenance message while updating the projects.
- Migrate the database using the Migrator package
- Deploy the API application package
- Deploy the UI application package
- Put the API application online, maybe some more tests to check that it's working correctly
- Put the UI application online.
If all this was on-prem, I would have no questions. It's the Azure part that I can't figure out because I don't know how to do these things on Azure via Octopus Deploy:
- Put an Azure App Service offline/online (using an app_offline.htm file)
- Deploy the Migrator package to the API Azure App Service in a special folder(so that I don't overwrite the API deployment) and run the migrator: dotnet [migrator.dll] -q
I tried using the Octopus Deploy "Deploy an Azure Web App" but this step won't let me also deploy the migrator package and run it before the API package is deployed. Or does it? I don't know how.
I tried using the "Run an Azure PowerShell script" but this executes on the Octopus Deploy server and not on the Azure App Service environment right?
Maybe there are other, even better, approaches deploying this setup to Azure?
azure aspnetboilerplate octopus-deploy asked Nov 14 '18 at 13:28
JorgJorg
84
I'm using the ASP.NET Core & Angular startup template from ASP.NET Boilerplate with Multi-Tenancy disabled: 1 database with a single tenant(Default).
I'm also using TeamCity to build/test/publish the projects available in the startup template so I end up with 3 NuGet packages that are getting pushed to Octopus Deploy:
- API (Host project, ASP.NET Core Web Application)
- Migrator (Console application, capable of migrating the database(s))
- UI (Angular App)
I want to deploy this setup to Azure with Octopus Deploy(self hosted, v2018.9.0) in the following way using 2 App Services(Host & UI) and 1 Azure SQL database(Host):
- Take the UI and API applications offline, displaying a friendly maintenance message while updating the projects.
- Migrate the database using the Migrator package
- Deploy the API application package
- Deploy the UI application package
- Put the API application online, maybe some more tests to check that it's working correctly
- Put the UI application online.
If all this was on-prem, I would have no questions. It's the Azure part that I can't figure out because I don't know how to do these things on Azure via Octopus Deploy:
- Put an Azure App Service offline/online (using an app_offline.htm file)
- Deploy the Migrator package to the API Azure App Service in a special folder(so that I don't overwrite the API deployment) and run the migrator: dotnet [migrator.dll] -q
I tried using the Octopus Deploy "Deploy an Azure Web App" but this step won't let me also deploy the migrator package and run it before the API package is deployed. Or does it? I don't know how.
I tried using the "Run an Azure PowerShell script" but this executes on the Octopus Deploy server and not on the Azure App Service environment right?
Maybe there are other, even better, approaches deploying this setup to Azure?
azure aspnetboilerplate octopus-deploy azure aspnetboilerplate octopus-deploy asked Nov 14 '18 at 13:28
JorgJorg
84
asked Nov 14 '18 at 13:28
JorgJorg
84
asked Nov 14 '18 at 13:28
JorgJorg
84
asked Nov 14 '18 at 13:28
JorgJorg
84
asked Nov 14 '18 at 13:28
JorgJorg
84
84
Are you trying to make simple schema updates to your database while keeping the data or are you bringing a whole new db? Are you going offline by choice because with App Services you could deploy and update without ever going offline.
– Simon Bourdeau
Nov 14 '18 at 21:18
Simple schema changes, it's EF Core using migrations. When I update the database(before the API is updated), it can cause issues with the API project not updated yet right? E.g. column renames etc. As I understand when deploying a new version of a Web App it's a new instance right? So no need to go offline indeed if the schema changes are backwards compatible, but what if they aren't?
– Jorg
Nov 15 '18 at 7:52
As a rule of thumb I don't make schema changes that are not backwards compatible on a production load db.
– Simon Bourdeau
Nov 15 '18 at 18:54
add a comment |
Are you trying to make simple schema updates to your database while keeping the data or are you bringing a whole new db? Are you going offline by choice because with App Services you could deploy and update without ever going offline.
– Simon Bourdeau
Nov 14 '18 at 21:18
Simple schema changes, it's EF Core using migrations. When I update the database(before the API is updated), it can cause issues with the API project not updated yet right? E.g. column renames etc. As I understand when deploying a new version of a Web App it's a new instance right? So no need to go offline indeed if the schema changes are backwards compatible, but what if they aren't?
– Jorg
Nov 15 '18 at 7:52
As a rule of thumb I don't make schema changes that are not backwards compatible on a production load db.
– Simon Bourdeau
Nov 15 '18 at 18:54
Are you trying to make simple schema updates to your database while keeping the data or are you bringing a whole new db? Are you going offline by choice because with App Services you could deploy and update without ever going offline.
– Simon Bourdeau
Nov 14 '18 at 21:18
Are you trying to make simple schema updates to your database while keeping the data or are you bringing a whole new db? Are you going offline by choice because with App Services you could deploy and update without ever going offline.
– Simon Bourdeau
Nov 14 '18 at 21:18
Simple schema changes, it's EF Core using migrations. When I update the database(before the API is updated), it can cause issues with the API project not updated yet right? E.g. column renames etc. As I understand when deploying a new version of a Web App it's a new instance right? So no need to go offline indeed if the schema changes are backwards compatible, but what if they aren't?
– Jorg
Nov 15 '18 at 7:52
Simple schema changes, it's EF Core using migrations. When I update the database(before the API is updated), it can cause issues with the API project not updated yet right? E.g. column renames etc. As I understand when deploying a new version of a Web App it's a new instance right? So no need to go offline indeed if the schema changes are backwards compatible, but what if they aren't?
– Jorg
Nov 15 '18 at 7:52
As a rule of thumb I don't make schema changes that are not backwards compatible on a production load db.
– Simon Bourdeau
Nov 15 '18 at 18:54
As a rule of thumb I don't make schema changes that are not backwards compatible on a production load db.
– Simon Bourdeau
Nov 15 '18 at 18:54
add a comment |
1 Answer
1
active
oldest
votes
You can use App service slots to swap in/out version of your logical applications. When you swap there's a warming up that occurs and no loss of traffic.
So basically deploy to backup slot, then swap production with backup slot.
For the db I don't think your strategy is valid. There are some assumptions you are making that will not make your life easy. I would look at handling the db deployment separately with no breaking changes but that's my opinion.
I'm not familiar with Octopus or TeamCity so I won't go into details about those.
answered Nov 15 '18 at 18:59
Simon BourdeauSimon Bourdeau
19114
It's not an assumption, it's a scenario I would like to support, if possible. I know it's not easy, hence the question. The steps I mentioned would support such a scenario(though with downtime, so that's a con). No breaking db changes when migrating a db should always be the preference. The rule of thumb so you will.
– Jorg
Nov 16 '18 at 15:05
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53301360%2fmigrate-database-when-deploying-to-azure-app-service%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
You can use App service slots to swap in/out version of your logical applications. When you swap there's a warming up that occurs and no loss of traffic.
So basically deploy to backup slot, then swap production with backup slot.
For the db I don't think your strategy is valid. There are some assumptions you are making that will not make your life easy. I would look at handling the db deployment separately with no breaking changes but that's my opinion.
I'm not familiar with Octopus or TeamCity so I won't go into details about those.
answered Nov 15 '18 at 18:59
Simon BourdeauSimon Bourdeau
19114
It's not an assumption, it's a scenario I would like to support, if possible. I know it's not easy, hence the question. The steps I mentioned would support such a scenario(though with downtime, so that's a con). No breaking db changes when migrating a db should always be the preference. The rule of thumb so you will.
– Jorg
Nov 16 '18 at 15:05
add a comment |
You can use App service slots to swap in/out version of your logical applications. When you swap there's a warming up that occurs and no loss of traffic.
So basically deploy to backup slot, then swap production with backup slot.
For the db I don't think your strategy is valid. There are some assumptions you are making that will not make your life easy. I would look at handling the db deployment separately with no breaking changes but that's my opinion.
I'm not familiar with Octopus or TeamCity so I won't go into details about those.
answered Nov 15 '18 at 18:59
Simon BourdeauSimon Bourdeau
19114
It's not an assumption, it's a scenario I would like to support, if possible. I know it's not easy, hence the question. The steps I mentioned would support such a scenario(though with downtime, so that's a con). No breaking db changes when migrating a db should always be the preference. The rule of thumb so you will.
– Jorg
Nov 16 '18 at 15:05
add a comment |
You can use App service slots to swap in/out version of your logical applications. When you swap there's a warming up that occurs and no loss of traffic.
So basically deploy to backup slot, then swap production with backup slot.
For the db I don't think your strategy is valid. There are some assumptions you are making that will not make your life easy. I would look at handling the db deployment separately with no breaking changes but that's my opinion.
I'm not familiar with Octopus or TeamCity so I won't go into details about those.
answered Nov 15 '18 at 18:59
Simon BourdeauSimon Bourdeau
19114
You can use App service slots to swap in/out version of your logical applications. When you swap there's a warming up that occurs and no loss of traffic.
So basically deploy to backup slot, then swap production with backup slot.
For the db I don't think your strategy is valid. There are some assumptions you are making that will not make your life easy. I would look at handling the db deployment separately with no breaking changes but that's my opinion.
I'm not familiar with Octopus or TeamCity so I won't go into details about those.
answered Nov 15 '18 at 18:59
Simon BourdeauSimon Bourdeau
19114
answered Nov 15 '18 at 18:59
Simon BourdeauSimon Bourdeau
19114
answered Nov 15 '18 at 18:59
Simon BourdeauSimon Bourdeau
19114
answered Nov 15 '18 at 18:59
Simon BourdeauSimon Bourdeau
19114
19114
It's not an assumption, it's a scenario I would like to support, if possible. I know it's not easy, hence the question. The steps I mentioned would support such a scenario(though with downtime, so that's a con). No breaking db changes when migrating a db should always be the preference. The rule of thumb so you will.
– Jorg
Nov 16 '18 at 15:05
add a comment |
It's not an assumption, it's a scenario I would like to support, if possible. I know it's not easy, hence the question. The steps I mentioned would support such a scenario(though with downtime, so that's a con). No breaking db changes when migrating a db should always be the preference. The rule of thumb so you will.
– Jorg
Nov 16 '18 at 15:05
It's not an assumption, it's a scenario I would like to support, if possible. I know it's not easy, hence the question. The steps I mentioned would support such a scenario(though with downtime, so that's a con). No breaking db changes when migrating a db should always be the preference. The rule of thumb so you will.
– Jorg
Nov 16 '18 at 15:05
It's not an assumption, it's a scenario I would like to support, if possible. I know it's not easy, hence the question. The steps I mentioned would support such a scenario(though with downtime, so that's a con). No breaking db changes when migrating a db should always be the preference. The rule of thumb so you will.
– Jorg
Nov 16 '18 at 15:05
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53301360%2fmigrate-database-when-deploying-to-azure-app-service%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Are you trying to make simple schema updates to your database while keeping the data or are you bringing a whole new db? Are you going offline by choice because with App Services you could deploy and update without ever going offline.
– Simon Bourdeau
Nov 14 '18 at 21:18
Simple schema changes, it's EF Core using migrations. When I update the database(before the API is updated), it can cause issues with the API project not updated yet right? E.g. column renames etc. As I understand when deploying a new version of a Web App it's a new instance right? So no need to go offline indeed if the schema changes are backwards compatible, but what if they aren't?
– Jorg
Nov 15 '18 at 7:52
As a rule of thumb I don't make schema changes that are not backwards compatible on a production load db.
– Simon Bourdeau
Nov 15 '18 at 18:54