зеркало из https://github.com/Azure/azure-saas.git
docs almost done
This commit is contained in:
Landon Pierce
Родитель
ea1ac06d76
Коммит
ddfadad889
|
|
@ -4,17 +4,14 @@ title: "Caveats & Limitations"
|
|||
weight: 100
|
||||
---
|
||||
|
||||
**Caveat**: This reference implementation does not provide support for per-tenant “local” users (i.e., all users will be accessing all tenants, there will be no landon@tenant1 vs landon@tenant2, it will be just landon@email.com).
|
||||
There are a few caveats of the identity solution provided within this reference implementation that you should be aware of.
|
||||
|
||||
**Caveat**: This version only supports “local” users and social identities and does not provide support for configuring federation with other Identity Providers.
|
||||
- This reference implementation does not provide support for per-tenant “local” users. All users will be stored in a singular B2C tenant and the user objects themselves will not be separated by the tenant they signed up with. For example, if you had `jill@contoso.com` sign up to tenant 1, they would also be able to sign into tenant 2, tenant 3, and tenant 4 with the same `jill@contoso.com` account. You may still control what tenants they have roles under via the permissions that come back in their JWT claims.
|
||||
|
||||
**Caveat**: Even if future versions provide support for configuring federation with additional Identity Providers (IdP), it will not provide support for “per-tenant federation” (i.e., where each tenant could bring their own IdP). This is primarily due to limitations in Azure AD B2C which make it additional work to manage “per-tenants” users/policies within a directory:
|
||||
* Each federation is configured via directory-wide policy and there is a limit of 200 policies on a directory.
|
||||
- The current version only supports “local” users and social identities and does not provide support for configuring federation with other Identity Providers.
|
||||
|
||||
**Caveat**: If all tenants can be assumed to have their own Azure Active Directory (regular B2B), then per-tenant federation could be implemented using Azure AD (multitenant) federation identity provider with “application code” doing the authorization based on specific tenant id claim.
|
||||
- Future versions will likely not provide support for “per-tenant federation” (i.e., where each tenant could bring their own IdP). This is primarily due to limitations in Azure AD B2C which introduce significant overhead when attempting to manage “per-tenants” users & policies within a directory.
|
||||
- ie. It is possible, but each federation is configured via directory-wide policy and there is a limit of 200 policies on a directory.
|
||||
- If all tenants can be assumed to have their own Azure Active Directory (regular B2B), then per-tenant federation could be implemented using Azure AD (multitenant) federation identity provider with the application code doing the authorization based on specific tenant id claim. However, if each tenant wants to be able to configure their own completely different IdP (e.g., Okta, Ping, Auth0, Cognito), it would require additional work due to policy limits.
|
||||
|
||||
However, if each tenant wants to be able to configure their own completely different IdP (e.g., Okta, Ping, Auth0, Cognito), it would require additional work due to policy limits.
|
||||
|
||||
|
||||
|
||||
https://github.com/AzureAD/microsoft-identity-web/wiki/b2c-limitations
|
||||
- Azure AD B2C has a documented limitation preventing API chaining via the OAuth 2.0 On-Behalf-Of flow. You may request a token to call an API via a web app, but not an API via an API. See the [B2C Limitations](https://github.com/AzureAD/microsoft-identity-web/wiki/b2c-limitations) page for more information.
|
||||
|
|
@ -11,14 +11,13 @@ The [SaaS.Permissions.Service](https://github.com/Azure/azure-saas/tree/main/src
|
|||
1. Handles CRUD operations from the rest of the solution for permission data
|
||||
2. Serves as an endpoint for the [Identity Provider](../identity-provider) to retrieve permission data in order to enrich the user token with claims
|
||||
|
||||
|
||||
## How to Run Locally
|
||||
|
||||
Instructions to get this module running on your local dev machine are located in the project [readme.md](https://github.com/Azure/azure-saas/tree/main/src/Saas.Identity/Saas.Permissions).
|
||||
Instructions to get this module running on your local dev machine are located in the module's [readme.md](https://github.com/Azure/azure-saas/tree/main/src/Saas.Identity/Saas.Permissions).
|
||||
|
||||
### Configuration and Secrets
|
||||
|
||||
A list of app settings and secrets can be found in the module's [readme.md](https://github.com/Azure/azure-saas/tree/main/src/Saas.Identity/Saas.Permissions). All non-secret values will have a default value in the `appsettings.json` file. All secret values will need to be set using the [.NET secrets manager](https://docs.microsoft.com/en-us/aspnet/core/security/app-secrets?view=aspnetcore-6.0&tabs=windows) when running the project locally, as it is not reccomended to have these secret values in your `appsettings.json` file.
|
||||
A list of app settings and secrets can be found in the module's [readme.md](https://github.com/Azure/azure-saas/tree/main/src/Saas.Identity/Saas.Permissions). All non-secret values will have a default value in the `appsettings.json` file. All secret values will need to be set using the [.NET secrets manager](https://docs.microsoft.com/en-us/aspnet/core/security/app-secrets?view=aspnetcore-6.0&tabs=windows) when running the module locally, as it is not reccomended to have these secret values in your `appsettings.json` file.
|
||||
|
||||
When deployed to Azure, the application is configured to load in its secrets from [Azure Key Vault](https://docs.microsoft.com/en-us/azure/key-vault/general/overview) instead. If you deploy the project using our bicep templates from the Quick Start guide, the modules will be deployed to an app service which accesses the key vault using a [System Assigned Managed Identity](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview). The Permissions Service module is also configured with [key name prefixes](https://docs.microsoft.com/en-us/aspnet/core/security/key-vault-configuration?view=aspnetcore-6.0#use-a-key-name-prefix) to only import secrets with the prefix of `permissions-`, as other modules share the same keyvault.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,22 +5,23 @@ weight: 90
|
|||
---
|
||||
## Overview
|
||||
|
||||
The [SaaS.Application.Web](https://github.com/Azure/azure-saas/tree/main/src/Saas.Application) module is a stub application demonstrating where users of the ASDK project would insert their code. It is the end user, customer facing application that the SaaS solution is designed around.
|
||||
The [SaaS.Application.Web](https://github.com/Azure/azure-saas/tree/main/src/Saas.Application) module is a stub application demonstrating where users of the ASDK project would insert their code. It is the end user, customer facing application written in ASP.NET 6.0 that the multitenant SaaS solution is designed around.
|
||||
|
||||
## How do I use this application?
|
||||
Different scenarios: greenfield, port application, etc.
|
||||
|
||||
Need to be very crisp about what users need to do to start using this.
|
||||
|
||||
## Design Considerations
|
||||
|
||||
- State Management
|
||||
title: "Sample SaaS Application"
|
||||
---
|
||||
|
||||
Saas.Application is an example of a multi-tenant application so that you can see where to put your own application logic.
|
||||
|
||||
## Running Locally
|
||||
## How to Run Locally
|
||||
|
||||
Instructions to get this module running on your local dev machine are located here:
|
||||
https://github.com/Azure/azure-saas/tree/main/src/Saas.Application
|
||||
|
||||
## Design
|
||||
|
||||
### Dependencies
|
||||
|
||||
None
|
||||
|
||||
### Consumers
|
||||
|
||||
End Users
|
||||
|
||||
## How do I use this application?
|
||||
|
||||
This application is designed for you to immediately start writing your own code. All you need to do to use this module is clone the ASDK repo and begin building your SaaS application inside of it. If you are not using ASDK in a greenfield scenario (ie you're porting your application or otherwise), you may choose to replace this application entirely with one that you have already.
|
||||
|
|
|
|||
|
|
@ -8,6 +8,14 @@ weight: 100
|
|||
|
||||
The SaaS.Notifications module is a relatively simple [Azure Logic App](https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-overview) that gets deployed to enable email sending from the rest of the solution. It is deployed with an HTTP trigger that takes in a JSON payload with fields required to send an email.
|
||||
|
||||
## Design
|
||||
### Dependencies
|
||||
|
||||
- Email provider of choice, once configured
|
||||
### Consumers
|
||||
|
||||
- [SaaS.SignupAdministration.Web](../signup-administration)
|
||||
|
||||
## Logic App Configuration
|
||||
|
||||
### Input
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ Instructions to get this module running on your local dev machine are located in
|
|||
|
||||
### Configuration and Secrets
|
||||
|
||||
A list of app settings and secrets can be found in the module's [readme.md](https://github.com/Azure/azure-saas/tree/main/src/Saas.Identity/Saas.Permissions). All non-secret values will have a default value in the `appsettings.json` file. All secret values will need to be set using the [.NET secrets manager](https://docs.microsoft.com/en-us/aspnet/core/security/app-secrets?view=aspnetcore-6.0&tabs=windows) when running the project locally, as it is not reccomended to have these secret values in your `appsettings.json` file.
|
||||
A list of app settings and secrets can be found in the module's [readme.md](https://github.com/Azure/azure-saas/tree/main/src/Saas.Identity/Saas.Permissions). All non-secret values will have a default value in the `appsettings.json` file. All secret values will need to be set using the [.NET secrets manager](https://docs.microsoft.com/en-us/aspnet/core/security/app-secrets?view=aspnetcore-6.0&tabs=windows) when running the module locally, as it is not reccomended to have these secret values in your `appsettings.json` file.
|
||||
|
||||
When deployed to Azure, the application is configured to load in its secrets from [Azure Key Vault](https://docs.microsoft.com/en-us/azure/key-vault/general/overview) instead. If you deploy the project using our bicep templates from the Quick Start guide, the modules will be deployed to an app service which accesses the key vault using a [System Assigned Managed Identity](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview). The SignupAdmin module is also configured with [key name prefixes](https://docs.microsoft.com/en-us/aspnet/core/security/key-vault-configuration?view=aspnetcore-6.0#use-a-key-name-prefix) to only import secrets with the prefix of `signupadmin-`, as other modules share the same keyvault.
|
||||
|
||||
|
|
@ -43,7 +43,7 @@ When deployed to Azure, the application is configured to load in its secrets fro
|
|||
|
||||
### Authentication
|
||||
|
||||
The SignupAdmin site uses the [Microsoft Authentication Library (MSAL)](https://docs.microsoft.com/en-us/azure/active-directory/develop/msal-overview) to handle the [flow](../identity/identity-flows#sign-in) of signing in and parsing the user token from the Azure B2C. The identity provider must be configured properly for this to work, and you must provide certain configuration values to the SignupAdmin site for it to properly communicate with B2C. These config values can be found in the project's [readme.md](https://github.com/Azure/azure-saas/tree/main/src/Saas.SignupAdministration).
|
||||
The SignupAdmin site uses the [Microsoft Authentication Library (MSAL)](https://docs.microsoft.com/en-us/azure/active-directory/develop/msal-overview) to handle the [flow](../identity/identity-flows#sign-in) of signing in and parsing the user token from the Azure B2C. The identity provider must be configured properly for this to work, and you must provide certain configuration values to the SignupAdmin site for it to properly communicate with B2C. These config values can be found in the module's [readme.md](https://github.com/Azure/azure-saas/tree/main/src/Saas.SignupAdministration).
|
||||
|
||||
For communication with the SaaS.Admin.Service, the SignupAdmin site also uses the MSAL to request an access token, using the signed in users existing token, to use in the Authorization header of all requests. This new token is specific to the SaaS.Admin.Service and will be requested from the Identity Provider with a specific scope. This type of exchange is known as an [OAuth 2.0 On-Belf-Of flow](https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow).
|
||||
|
||||
|
|
@ -60,19 +60,19 @@ When a new tenant is created, the SignupAdmin site will make a REST call to the
|
|||
|
||||
## FAQ and Design Considerations
|
||||
|
||||
- For the onboarding workflow, we are keeping track of the state in memory. This is fine for demo purposes and low traffic systems, but this is not a great pattern when introducing horizontally scaled backends. It is reccomended that you replace the JsonPersistenceProvider (the service that stores the state) with another implementation backed by an external cache (ex: Redis, CosmosDB, etc). Instructions on where to do this can be found in the module's [readme.md](https://github.com/Azure/azure-saas/tree/main/src/Saas.SignupAdministration)
|
||||
|
||||
- For ease of management, we have chosen to incorporate the global administrative functionality into this application. You may choose to separate this functionality into a different module if you require more administrative functionality than just tenant and user management
|
||||
|
||||
- A better solution for sending transactional emails might be to emit an event or message from the application, and building a notifications system to subscribe to those events. You could then build other applications to consume those events for other business functions as well. This style of architecture is called an [Event Driven](https://docs.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven) architecture. We decided to not go this route (yet!) with this project to keep it simple, but it is something to be considered when looking at your overall technical landscape.
|
||||
|
||||
## Signup Administration User Flows
|
||||
|
||||
## Signup Administration Flows
|
||||
|
||||
|
||||
## Sign In
|
||||
### Sign In
|
||||
|
||||
See the [Sign-In Flow](./Identity/identity-flows.md##Sign-In) in Identity Flows.
|
||||
|
||||
## Onboarding Flow
|
||||
### Onboarding Flow
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
|
|
@ -111,7 +111,7 @@ admin-->>signup : Tenant Created
|
|||
admin-->>user : Tenant Created Confirmation Page
|
||||
```
|
||||
|
||||
## Add New Tenant Admin - Existing User
|
||||
### Add New Tenant Admin - Existing User
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
|
|
@ -137,7 +137,7 @@ admin-->>signup : Ok
|
|||
signup-->>user : Ok
|
||||
```
|
||||
|
||||
## Add New Tenant Admin - User Does Not Exist
|
||||
### Add New Tenant Admin - User Does Not Exist
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
|
|
|
|||
|
|
@ -1,20 +1,16 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Design"
|
||||
linkTitle: "Design"
|
||||
title: "Architecture Diagrams"
|
||||
linkTitle: "Architecture Diagrams"
|
||||
weight: 15
|
||||
description: "Getting Started with the Azure SaaS Dev Kit"
|
||||
---
|
||||
|
||||
|
||||
## Architecture Diagrams
|
||||
|
||||
### Overview & Dependencies
|
||||
|
||||
|
||||
|
||||
|
||||
### Identity Framework
|
||||
|
||||
|
||||
|
||||
### User Types
|
||||
|
|
@ -36,7 +36,8 @@ Deploying to Azure is easy thanks to our pre-configured ARM (Azure Resource Mana
|
|||
|
||||
This button will take you to the Azure portal, passing it the template. You'll be asked a few questions, and then the solution will be up and running in just a few minutes. You will need your B2C configuration values and secrets from step 1.
|
||||
|
||||
[](https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2Fazure-saas%2Fmain%2Fsrc%2FSaas.Deployment%2FSaas.Deployment.Root%2Fazuredeploy.json/createUIDefinitionUri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2Fazure-saas%2Fmain%2Fsrc%2FSaas.Deployment%2FSaas.Deployment.Root%2FcreateUiDefinition.json)
|
||||
**Deployment Coming Soon!**
|
||||
<!-- [](https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2Fazure-saas%2Fmain%2Fsrc%2FSaas.Deployment%2FSaas.Deployment.Root%2Fazuredeploy.json/createUIDefinitionUri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2Fazure-saas%2Fmain%2Fsrc%2FSaas.Deployment%2FSaas.Deployment.Root%2FcreateUiDefinition.json) -->
|
||||
|
||||
## 2.c. (Advanced) Deploying to Azure - Single Module
|
||||
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@ weight: 200
|
|||
* [ISV Considerations for Azure landing zones](https://aka.ms/isv-landing-zones)
|
||||
* [Azure Well-Architected Framework](https://docs.microsoft.com/en-us/azure/architecture/framework/)
|
||||
* [WingTips Tickets SaaS Application](https://docs.microsoft.com/en-us/azure/azure-sql/database/saas-tenancy-welcome-wingtip-tickets-app) - Provides details into tradeoffs with various tenancy models within the database layer.
|
||||
* [Multitenancy](http://aka.ms/multitenancy)
|
||||
|
||||
## Identity Focused
|
||||
|
||||
|
|
|
|||
|
|
@ -4,13 +4,13 @@ title: "SaaS Branding Considerations"
|
|||
weight: 10
|
||||
---
|
||||
|
||||
As a SaaS vendor, it's useful to understand where your branding ends, and the vendor branding begins. In other words, how will your software solution be positioned for your customer base.
|
||||
As a SaaS vendor, it's useful to understand where your branding ends, and the vendor branding begins. In other words, how will your software solution be positioned for your customer base?
|
||||
|
||||
> **Identity** plays a critical role within SaaS solutions. It's an area where extra planning early in your design is recommended.
|
||||
|
||||
## Common Customer Scenarios
|
||||
|
||||
These are common scenarios from the perspective of the customer / user. Understanding which scenario best aligns
|
||||
These are common scenarios from the perspective of the customer / user. Understanding which scenario best aligns to you is critical for designing your SaaS application for multitenancy.
|
||||
|
||||
### Scenario 1 - Pure B2B
|
||||
|
||||
|
|
|
|||
|
|
@ -4,11 +4,15 @@ title: "Contoso BadgeMeUp"
|
|||
weight: 20
|
||||
---
|
||||
|
||||
## Intro
|
||||
|
||||
For ease of explaining the project and who it might benefit, we created a few example "stories" to help users visualize the components. Contoso BadgeMeUp is one of those example stories.
|
||||
|
||||
## Context
|
||||
|
||||
|
||||
|
||||
Contoso BadgeMeUp is a SaaS B2B application that Contoso sells to companies that want a great tool to improve the culture within their organization.
|
||||
Contoso is a SaaS ISV (software vendor) that has a product, Contoso BadgeMeUp. Contoso BadgeMeUp is a SaaS B2B application that Contoso sells to companies that want a great tool to improve the culture within their organization.
|
||||
|
||||
> For more information about how this SaaS architecture compares to others, please see *Scenario 1* in [SaaS Branding Considerations](../branding-considerations-for-saas/#scenario-1---pure-b2b).
|
||||
|
||||
|
|
@ -18,8 +22,9 @@ Lucerne Publishing has recently purchased Contoso BadgeMeUp. They're currently u
|
|||
|
||||
### Onboarding
|
||||
|
||||
1. Phil in accounting browsed the plans available at BadgeMeUp.Contoso.com and selected the plan he thought would best fit their companies needs.
|
||||
2. Sandy navigates to BadgeMeUp.Contoso.com and is automatically signed on with her companies credentials.
|
||||
1. Phil in accounting browsed the plans available at Signup.BadgeMeUp.Contoso.com and selected the plan he thought would best fit their companies needs.
|
||||
2. Sandy navigates to BadgeMeUp.Contoso.com/lucernepublishing and signs in using her Active Directory credentials.
|
||||
3. After Sandy creates an account, Phil can then go to Signup.BadgeMeUp.Contoso.com/admin to see his previously created tenant and grant Sandy elevation permissions if he wishes.
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
|
|
@ -36,6 +41,4 @@ graph LR
|
|||
subgraph "fa:fa-building Contoso"
|
||||
isv
|
||||
end
|
||||
```
|
||||
|
||||
> Note: Currently, Sandy has to sign up for the service. **How do we simplify?**
|
||||
```
|
||||
|
|
@ -2,6 +2,7 @@
|
|||
type: docs
|
||||
title: "Contoso Tickets"
|
||||
weight: 20
|
||||
toc_hide: true
|
||||
---
|
||||
|
||||
## Context
|
||||
|
|
|
|||
|
|
@ -4,38 +4,93 @@ title: "DevOps Workflows"
|
|||
weight: 100
|
||||
---
|
||||
|
||||
For your convenience, we have provided some sample GitHub workflows that you can use to build and deploy code changes to each module. They were created as a baseline reference with the intent to be extensible when needed.
|
||||
|
||||
For your convenience, we have provided some sample GitHub workflows that you can use to build and deploy code changes to each module. These workflows are the same ones that we use to package and release the code to our test environment. They were created as a baseline reference with the intent to be extensible when needed.
|
||||
|
||||
## How does it work?
|
||||
There are 2 [reusable workflows](https://docs.github.com/en/actions/using-workflows/reusing-workflows) we have created which the process is based on.
|
||||
|
||||
Each module implements these re-usable workflows ensuring each build and deploy step taken is consistent across the entire solution. There are 2 github workflow files per module. Each module workflow file is responsible for defining when the workflow is triggered, setting up variables, and calling the correct reusable workflow.
|
||||
|
||||
There are 2 [reusable workflows](https://docs.github.com/en/actions/using-workflows/reusing-workflows) we have created which the process is based on.
|
||||
|
||||
Each module has 2 workflow files that implement these re-usable workflows ensuring each build and deploy step taken is consistent across the entire solution. Each module workflow file is responsible for defining when the workflow is triggered, setting up variables, and calling the correct reusable workflow.
|
||||
|
||||
### Process Outline
|
||||
#### **Build & Deploy to Staging**
|
||||
### **Build & Deploy to Staging**
|
||||
Workflow File: `template-pr-deploy.yml`
|
||||
|
||||
- `pr-deploy-saas-admin.yml`
|
||||
- `pr-deploy-saas-application.yml`
|
||||
- `pr-deploy-saas-permissions.yml`
|
||||
- `pr-deploy-saas-signupadministration.yml`
|
||||
|
||||
Triggered On: `Pull Request targeting main branch`
|
||||
|
||||
Input Variables:
|
||||
#### Input Variables
|
||||
|
||||
There are 3 jobs within this workflow: `build`, `create-deployment-slot`, and `deploy-to-slot`. Here is a high level overview of what each job does.
|
||||
| Input Name | Description | Default |
|
||||
|---------------------------------|--------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------|
|
||||
| dotnet_version | The version of the .NET project to build | |
|
||||
| artifact_name | The name of the artifact file produced | |
|
||||
| app_service_name | The name of the app service to deploy the artifact to | |
|
||||
| app_service_resource_group_name | The name of the resource group the app service resides in | |
|
||||
| project_build_path | The path of the folder that the .csproj for the module is in | |
|
||||
| slot_name | The name of the deployment slot slot to create and deploy to on the app service (Used for override, recommended to keep the default) | pr-${{github.event.pull_request.number}} |
|
||||
|
||||
##### `build`
|
||||
1. Run the .NET restore, build, and publish commands on the project. Project is determined by the `project_build_path` input variable.
|
||||
2. Publishes built .NET artifact to GitHub artifacts. Artifact is named with the string provided in the `artifact_name` input variable.
|
||||
#### Secrets
|
||||
|
||||
##### `create-deployment-slot`
|
||||
1. Logs into the Azure CLI with [credentials provided](https://docs.microsoft.com/en-us/azure/developer/github/connect-from-azure?tabs=azure-portal%2Cwindows#create-a-service-principal-and-add-it-as-a-github-secret) in the `AZURE_CREDENTIALS` secret.
|
||||
2. Runs Azure CLI command to create a new deployment slot in the app service provided in the `app_service_name` input variable. Slot name is provided via the `slot_name` input variable.
|
||||
- `AZURE_CREDENTIALS`
|
||||
- The devops pipeline must contain azure credentials for a service principal that has an appropriate access level to create a new app service slot and deploy to it. See [this](https://docs.microsoft.com/en-us/azure/developer/github/connect-from-azure?tabs=azure-portal%2Cwindows) document for setting up these credentials in your own repo.
|
||||
|
||||
##### `deploy-to-slot`
|
||||
#### Job Breakdown
|
||||
There are 3 jobs within this workflow: `build`, `create-deployment-slot`, and `deploy-to-slot`. Here is a high level overview of what each job does.
|
||||
|
||||
1. `build`
|
||||
1. Run the .NET restore, build, and publish commands on the project. Project is determined by the `project_build_path` input variable.
|
||||
2. Publishes built .NET artifact to GitHub artifacts. Artifact is named with the string provided in the `artifact_name` input variable.
|
||||
|
||||
2. `create-deployment-slot`
|
||||
1. Logs into the Azure CLI with [credentials provided](https://docs.microsoft.com/en-us/azure/developer/github/connect-from-azure?tabs=azure-portal%2Cwindows#create-a-service-principal-and-add-it-as-a-github-secret) in the `AZURE_CREDENTIALS` secret.
|
||||
2. Runs Azure CLI command to create a new deployment slot in the app service provided in the `app_service_name` input variable. Slot name is provided via the `slot_name` input variable.
|
||||
|
||||
3. `deploy-to-slot`
|
||||
Depends on the `build` and `create-deployment-slot` jobs to succeed in order to run.
|
||||
1. Downloads the build artifact from the `build` job. Downloaded artifact name is provided via the `artifact_name` input variable.
|
||||
2. Logs into the Azure CLI with [credentials provided](https://docs.microsoft.com/en-us/azure/developer/github/connect-from-azure?tabs=azure-portal%2Cwindows#create-a-service-principal-and-add-it-as-a-github-secret) in the `AZURE_CREDENTIALS` secret.
|
||||
3. Initiates deployment of the downloaded artifact to the app service and slot specified in `app_service_name` and `slot_name` respectively using the [azure/webapps-deploy](https://github.com/Azure/webapps-deploy) GitHub Action.
|
||||
1. Downloads the build artifact from the `build` job. Downloaded artifact name is provided via the `artifact_name` input variable.
|
||||
2. Logs into the Azure CLI with [credentials provided](https://docs.microsoft.com/en-us/azure/developer/github/connect-from-azure?tabs=azure-portal%2Cwindows#create-a-service-principal-and-add-it-as-a-github-secret) in the `AZURE_CREDENTIALS` secret.
|
||||
3. Initiates deployment of the downloaded artifact to the app service and slot specified in `app_service_name` and `slot_name` respectively using the [azure/webapps-deploy](https://github.com/Azure/webapps-deploy) GitHub Action.
|
||||
|
||||
###
|
||||
### **Swap Staging Slot into Production**
|
||||
|
||||
Workflow File: `template-pr-merge.yml`
|
||||
|
||||
Used By:
|
||||
|
||||
- `pr-merge-saas-admin.yml`
|
||||
- `pr-merge-saas-application.yml`
|
||||
- `pr-merge-saas-permissions.yml`
|
||||
- `pr-merge-saas-signupadministration.yml`
|
||||
|
||||
Triggered On: `Pull request close`
|
||||
|
||||
#### Input Variables
|
||||
|
||||
| Input Name | Description | Default |
|
||||
|---------------------------------|---------------------------------------------------------------------------------------------------------------------|------------------------------------------|
|
||||
| app_service_name | The name of the app service the slot is deployed to | |
|
||||
| app_service_resource_group_name | The name of the resource group the app service resides in | |
|
||||
| slot_name | The name of the deployment slot the staged code is deployed to (Used for override, recommended to keep the default) | pr-${{github.event.pull_request.number}} |
|
||||
|
||||
#### Secrets
|
||||
|
||||
- `AZURE_CREDENTIALS`
|
||||
- The devops pipeline must contain azure credentials for a service principal that has an appropriate access level to preform the swap operation on the app service in question. See [this](https://docs.microsoft.com/en-us/azure/developer/github/connect-from-azure?tabs=azure-portal%2Cwindows) document for setting up these credentials in your own repo.
|
||||
|
||||
#### Job Breakdown
|
||||
|
||||
There are 2 main jobs within this workflow: `swap-slot` and `delete-slot`
|
||||
|
||||
1. `swap-slot` - *This job only runs if the PR is closed AND merged. This job does not run if the PR is closed without merging.*
|
||||
1. Logs into the Azure CLI with [credentials provided](https://docs.microsoft.com/en-us/azure/developer/github/connect-from-azure?tabs=azure-portal%2Cwindows#create-a-service-principal-and-add-it-as-a-github-secret) in the `AZURE_CREDENTIALS` secret.
|
||||
2. Runs the Azure CLI command to swap the deployment slot named in the `slot_name` input variable with the production slot on the app service named in the `app_service_name` input variable.
|
||||
|
||||
2. `delete-slot` - This job will only run if the preceding step runs and succeeds. If the PR is closed without merging, the previous step will be skipped but this will still run.
|
||||
1. Logs into the Azure CLI with [credentials provided](https://docs.microsoft.com/en-us/azure/developer/github/connect-from-azure?tabs=azure-portal%2Cwindows#create-a-service-principal-and-add-it-as-a-github-secret) in the `AZURE_CREDENTIALS` secret.
|
||||
2. Runs the Azure CLI command to delete the deployment slot named in the `slot_name` input variable with the production slot on the app service named in the `app_service_name` input variable.
|
||||
|
||||
> **Important**: You may choose to not delete the deployment slot directly following a deployment to retain the ability to swap the slot back if there are any issues and you'd like to undo the deployment. Deleting the slot immediately after a deployment is most reccomended in a development/test environment where you may be deploying multiple times per day.
|
||||
|
|
|
|||
|
|
@ -8,10 +8,10 @@ description: ""
|
|||
|
||||
| Term | Description | Example |
|
||||
| ------------ | --------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
|
||||
| SaaS Vendor | The entity that owns the application and code etc. | Contoso Inc. |
|
||||
| Solution | The thing they are selling | Contoso Tickets |
|
||||
| Tenant | Instance of the said application that one can purchase/subscribe | Contoso Stadium, TD Garden, Joe's Coffee Shop |
|
||||
| Vendor Admin | People who work for the company that owns the application | Jane from Contoso accounting |
|
||||
| Tenant Admin | People who purchase or administer an instance of the application | Joe, owner of Joe's coffee shop. Adam, event coordinator of Joe's coffee shop |
|
||||
| Customer | People who use the application | Kathy, patron of Joe's coffee shop |
|
||||
| SaaS Vendor or ISV | The entity that owns the application and code and sells the SaaS product. | Contoso Inc. |
|
||||
| Solution | The application the SaaS Vendor is selling | Contoso Tickets |
|
||||
| Tenant | Instance of the said application that one can purchase/subscribe to | Contoso Stadium, Joe's Coffee Shop, Lucerne Publishing |
|
||||
| Global Admin | People who work for the SaaS Vendor that has access to see all data across the solution | Jane from Contoso accounting |
|
||||
| Tenant Admin | People who purchase or administer an instance of the application | Joe, owner of Joe's coffee shop. Adam, event coordinator of Joe's coffee shop |
|
||||
| Customer | People who use the application | Kathy, patron of Joe's coffee shop |
|
||||
| User | Term includes Vendor Admin, Subscription Admin, or Customer. Used to describe everyone. | Jane, Joe, Adam, and Kathy are all users |
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче