|
1 | 1 | ---
|
2 |
| -title: Review pull requests in pre-production environments in Azure Static Web Apps |
| 2 | +title: Review pull requests in pre-production environments |
3 | 3 | description: Learn how to use pre-production environments to review pull requests changes in Azure Static Web Apps.
|
4 | 4 | services: static-web-apps
|
5 | 5 | author: sinedied
|
6 | 6 | ms.service: static-web-apps
|
| 7 | +ms.custom: engagement-fy23 |
7 | 8 | ms.topic: conceptual
|
8 |
| -ms.date: 05/08/2020 |
| 9 | +ms.date: 10/27/2022 |
9 | 10 | ms.author: yolasors
|
10 | 11 | ---
|
11 | 12 |
|
12 |
| -# Review pull requests in pre-production environments in Azure Static Web Apps |
| 13 | +# Review pull requests in pre-production environments |
13 | 14 |
|
14 |
| -This article demonstrates how to use pre-production environments to review changes to applications deployed with [Azure Static Web Apps](overview.md). |
| 15 | +This article shows you how to use pre-production environments to review changes to applications that are deployed with [Azure Static Web Apps](overview.md). A pre-production environment is a fully functional staged version of your application that includes changes not available in production. |
15 | 16 |
|
16 |
| -A pre-production (staging) environment is a fully-functional staged version of your application that includes changes not available in production. |
| 17 | +Azure Static Web Apps generates a GitHub Actions workflow in the repo. When a pull request is created against a branch that the workflow watches, the pre-production environment gets built. The pre-production environment stages the app, so you can review the changes before you push them to production. |
17 | 18 |
|
18 |
| -Azure Static Web Apps generates a GitHub Actions workflow in the repository. When a pull request is created against a branch that the workflow watches, the pre-production environment is built. The pre-production environment stages the app, enables you to perform reviews before pushing them to production. |
| 19 | +You can do the following tasks within pre-production environments: |
19 | 20 |
|
20 |
| -Multiple pre-production environments can co-exist at the same time when using Azure Static Web Apps. Each time you create a pull request against the watched branch, a staged version with your changes is deployed to a distinct pre-production environment. |
21 |
| - |
22 |
| -There are many benefits of using pre-production environments. For example, you can: |
23 |
| - |
24 |
| -- Review visual changes between production and staging. For example, viewing updates to content and layout. |
25 |
| -- Demonstrate the changes to your team. |
26 |
| -- Compare different versions of your application. |
27 |
| -- Validate changes using acceptance tests. |
28 |
| -- Perform sanity checks before deploying to production. |
| 21 | +- Review visual changes between production and staging, like updates to content and layout |
| 22 | +- Demonstrate the changes to your team |
| 23 | +- Compare different versions of your application |
| 24 | +- Validate changes using acceptance tests |
| 25 | +- Perform sanity checks before you deploy to production |
29 | 26 |
|
30 | 27 | > [!NOTE]
|
31 |
| -> Pull requests and pre-production environments are currently only supported in GitHub Actions deployments. |
| 28 | +> Pull requests and pre-production environments are only supported in GitHub Actions deployments. |
32 | 29 |
|
33 | 30 | ## Prerequisites
|
34 | 31 |
|
35 |
| -- An existing GitHub repository configured with Azure Static Web Apps. See [Building your first static app](getting-started.md) if you don't have one. |
| 32 | +- An existing GitHub repo configured with Azure Static Web Apps. See [Building your first static app](getting-started.md) if you don't have one. |
36 | 33 |
|
37 | 34 | ## Make a change
|
38 | 35 |
|
39 |
| -Begin by making a change in your repository. You can do it directly on GitHub as shown in the following steps. |
| 36 | +Make a change in your repo directly on GitHub, as shown in the following steps. |
40 | 37 |
|
41 |
| -1. Go to your project's repository on GitHub, then select **Branch** to create a new branch. |
| 38 | +1. Go to your project's repo on GitHub, and then select **Branch**. |
42 | 39 |
|
43 | 40 | :::image type="content" source="./media/review-publish-pull-requests/create-branch.png" alt-text="Create new branch using GitHub interface":::
|
44 | 41 |
|
45 |
| - Type a branch name and select **Create branch**. |
| 42 | +1. Enter a branch name and select **Create branch**. |
46 | 43 |
|
47 |
| -2. Go to your _app_ folder and change some text content. For example, you can change a title or paragraph. Once you found the file you want to edit, select **Edit** to make the change. |
| 44 | +1. Go to your _app_ folder and change some text content, like a title or paragraph. Select **Edit** to make the change in the file. |
48 | 45 |
|
49 | 46 | :::image type="content" source="./media/review-publish-pull-requests/edit-file.png" alt-text="Edit file button in GitHub interface":::
|
50 | 47 |
|
51 |
| -3. After you make the changes, select **Commit changes** to commit your changes to the branch. |
| 48 | +1. Select **Commit changes** when you're done. |
52 | 49 |
|
53 |
| - :::image type="content" source="./media/review-publish-pull-requests/commit-changes.png" alt-text="Commit changes button in GitHub interface"::: |
| 50 | + :::image type="content" source="./media/review-publish-pull-requests/commit-changes.png" alt-text="Screenshot showing the Commit changes button in the GitHub interface."::: |
54 | 51 |
|
55 | 52 | ## Create a pull request
|
56 | 53 |
|
57 |
| -Next, create a pull request from this change. |
| 54 | +Create a pull request to publish your update. |
58 | 55 |
|
59 |
| -1. Open the **Pull request** tab of your project on GitHub: |
| 56 | +1. Open the **Pull request** tab of your project on GitHub. |
60 | 57 |
|
61 |
| - :::image type="content" source="./media/review-publish-pull-requests/tab.png" alt-text="Pull request tab in a GitHub repository"::: |
| 58 | + :::image type="content" source="./media/review-publish-pull-requests/tab.png" alt-text="Screenshot showing the pull request tab in a GitHub repo."::: |
62 | 59 |
|
63 |
| -2. Select **Compare & pull request** on your branch. |
| 60 | +1. Select **Compare & pull request**. |
64 | 61 |
|
65 |
| -3. You can optionally fill in some details about your changes, then select **Create pull request**. |
| 62 | +1. Optionally, enter details about your changes, and then select **Create pull request**. |
66 | 63 |
|
67 |
| - :::image type="content" source="./media/review-publish-pull-requests/open.png" alt-text="Pull request creation in GitHub"::: |
| 64 | + :::image type="content" source="./media/review-publish-pull-requests/open.png" alt-text="Screenshot showing the pull request creation in GitHub."::: |
68 | 65 |
|
69 |
| -You can assign reviewers and add comments to discuss your changes if needed. |
| 66 | +Assign reviewers and add comments to discuss your changes, if needed. |
70 | 67 |
|
71 |
| -> [!NOTE] |
72 |
| -> You can make multiple changes by pushing new commits to your branch. The pull request is then automatically updated to reflect all changes. |
| 68 | +Multiple pre-production environments can co-exist at the same time when you use Azure Static Web Apps. Each time you create a pull request against the watched branch, a staged version with your changes deploys to a distinct pre-production environment. |
73 | 69 |
|
74 |
| -## Review changes |
| 70 | +You can make multiple changes and push new commits to your branch. The pull request automatically updates to reflect all changes. |
75 | 71 |
|
76 |
| -After the pull request is created, the [GitHub Actions](https://github.com/features/actions) deployment workflow runs and deploys your changes to a pre-production environment. |
| 72 | +## Review changes |
77 | 73 |
|
78 |
| -Once the workflow has completed building and deploying your app, the GitHub bot adds a comment to your pull request which contains the URL of the pre-production environment. You can select this link to see your staged changes. |
| 74 | +The [GitHub Actions](https://github.com/features/actions) deployment workflow runs and deploys your pull request changes to a pre-production environment. |
79 | 75 |
|
80 |
| -:::image type="content" source="./media/review-publish-pull-requests/bot-comment.png" alt-text="Pull request comment with the pre-production URL"::: |
| 76 | +Once the workflow completes building and deploying your app, the GitHub bot adds a comment to your pull request, which contains the URL of the pre-production environment. |
81 | 77 |
|
82 |
| -Select the generated URL to see the changes. |
| 78 | +1. Select the pre-production URL to see your staged changes. |
83 | 79 |
|
84 |
| -If you take a closer look at the URL, you can see that it's composed like this: `https://<SUBDOMAIN-PULL_REQUEST_ID>.<AZURE_REGION>.azurestaticapps.net`. |
| 80 | + :::image type="content" source="./media/review-publish-pull-requests/bot-comment.png" alt-text="Screenshot of pull request comment with the pre-production URL."::: |
85 | 81 |
|
86 |
| -For a given pull request, the URL remains the same even if you push new updates. In addition to the URL staying constant, the same pre-production environment is reused for the life of the pull request. |
| 82 | + The URL is composed like this: `https://<SUBDOMAIN-PULL_REQUEST_ID>.<AZURE_REGION>.azurestaticapps.net`. For a given pull request, the URL remains the same, even if you push new updates. The same pre-production environment also gets reused for the life of the pull request. |
87 | 83 |
|
88 |
| -To automate the review process with end-to-end testing, the [Azure Static Web App Deploy GitHub Action](https://github.com/Azure/static-web-apps-deploy) has the `static_web_app_url` output variable. |
89 |
| -This URL can be referenced in the rest of your workflow to run your tests against the pre-production environment. |
| 84 | +To automate the review process with end-to-end testing, the [GitHub Action for deploying Azure Static Web Apps](https://github.com/Azure/static-web-apps-deploy) has the `static_web_app_url` output variable. |
| 85 | +You can reference this URL in the rest of your workflow to run your tests against the pre-production environment. |
90 | 86 |
|
91 | 87 | ## Publish changes
|
92 | 88 |
|
93 |
| -Once changes are approved, you can publish your changes to production by merging the pull request. |
| 89 | +Merge the pull request to publish to production. |
94 | 90 |
|
95 |
| -Select **Merge pull request**: |
| 91 | +1. Select **Merge pull request**. |
96 | 92 |
|
97 |
| -:::image type="content" source="./media/review-publish-pull-requests/merge.png" alt-text="Merge pull request button in GitHub interface"::: |
| 93 | + :::image type="content" source="./media/review-publish-pull-requests/merge.png" alt-text="Screenshot showing the Merge pull request button in GitHub interface."::: |
98 | 94 |
|
99 |
| -Merging copies your changes to the tracked branch (the "production" branch). Then, the deployment workflow starts on the tracked branch and the changes are live after your application has been rebuilt. |
| 95 | + Your changes get copied to the tracked branch (the "production" branch). Then, the deployment workflow starts on the tracked branch and the changes go live after your application rebuilds. |
100 | 96 |
|
101 |
| -To verify the changes in production, open your production URL to load the live version of the website. |
| 97 | +1. Open your production URL to load the live version of the website and verify. |
102 | 98 |
|
103 | 99 | ## Limitations
|
104 | 100 |
|
105 |
| -- Staged versions of your application are currently accessible publicly by their URL, even if your GitHub repository is private. |
| 101 | +- Anyone can access the staged versions of your application via their URL, even if your GitHub repo is private. |
106 | 102 |
|
107 | 103 | > [!WARNING]
|
108 |
| - > Be careful when publishing sensitive content to staged versions, as access to pre-production environments are not restricted. |
109 |
| -
|
110 |
| -- The number of pre-production environments available for each app deployed with Static Web Apps depends on the [hosting plan](plans.md) you are using. For example, with the Free tier you can have 3 pre-production environments in addition to the production environment. |
111 |
| - |
112 |
| -- Pre-production environments are not geo-distributed. |
| 104 | + > Be careful with sensitive content, since anyone can access pre-production environments. |
113 | 105 |
|
114 |
| -- Currently, only GitHub Actions deployments support pre-production environments. |
| 106 | +- The number of pre-production environments available for each app deployed with Static Web Apps depends your [hosting plan](plans.md). For example, with the [Free tier](https://azure.microsoft.com/pricing/details/devops/azure-devops-services/) you can have three pre-production environments along with the production environment. |
| 107 | +- Pre-production environments aren't geo-distributed. |
| 108 | +- Only GitHub Actions deployments support pre-production environments. |
115 | 109 |
|
116 | 110 | ## Next steps
|
117 | 111 |
|
118 | 112 | > [!div class="nextstepaction"]
|
119 |
| -> [Branch preview environments](branch-environments.md) |
| 113 | +> [Create branch preview environments](branch-environments.md) |
0 commit comments