Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XS✔ ◾ Removed extra row + added emojis #6926

Merged
merged 1 commit into from
Oct 8, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -27,9 +27,8 @@ We do this by including deployment batch files in the solution, and specifying t
|---|---|---|
| **Deployment Overview** | 1. A separate build is created per target environment <br /> 2. The MS Deploy parameters are put into the MSBuild parameters setting on the process template <br /> 3. The build for the shared development server is set to be a CI build so it is executed on every check-in | 1. One batch file per target environment is created and checked into source control alongside the web project<br /> 2. Each batch file is accompanied by a corresponding Web Deploy Parameterisation XML file with environment specific settings<br /> 3. The build process template is modified to call the batch file to continuously deploy to the shared development server |
| **Deployment Process** | 1. The build is automatically deployed to the shared dev server<br /> 2. Lots of testing occurs and we decide to deploy to staging<br /> 3. We can just kick off the staging build<br /> 4. A whole lot of testing occurs and we want to deploy to production<br /> 5. We can kick off a production build, but this will deploy the latest source code to production<br /> 6. If we want to deploy the version of the software that we have deployed to staging we have to get that specific version from source control, and then do a production build of it | 1. The build is automatically deployed to the shared dev server<br /> 2. Lots of testing occurs and we decide to deploy to staging<br /> 3. The batch file for any build can be executed and the build deployed to staging<br /> 4. A whole lot of testing occurs on staging and then we decide to deploy the same build to production<br /> <br />**Note:** We just call the batch file in the folder to do the deployment. No new build is required |
| | | |
| **Benefits** | 1. No need to create batch files or modify the process template | 1. Builds are created once, and can then be deployed many times to any environment, at any point in time (Build Once, Deploy Many)<br /> 2. When deploying to production, we use exactly the same build package as was used to deploy to staging<br /> 3. The custom build process template only does the deployment if the build succeeds and all the unit tests pass<br /> 4. Anyone with access to the batch file can deploy… including the Product Owner!<br /> 5. You only need one build per project |
| **Cons** | 1. Without modifying the build process template, the build will deploy even if the unit tests fail<br /> 2. To deploy a specific build to a particular server, it is necessary to get the code from source control, and then do a build<br /> 3. Only developers can deploy<br />4. You need a build per environment for each project<br /> 5. Build Once, Deploy Once. (You can't redeploy a build to a different environment) | 1. You must customize the build process template to execute the specified batch file from the build folder<br /> 2. We have to create custom batch files |
| **👍 Benefits** | 1. No need to create batch files or modify the process template | 1. Builds are created once, and can then be deployed many times to any environment, at any point in time (Build Once, Deploy Many)<br /> 2. When deploying to production, we use exactly the same build package as was used to deploy to staging<br /> 3. The custom build process template only does the deployment if the build succeeds and all the unit tests pass<br /> 4. Anyone with access to the batch file can deploy… including the Product Owner!<br /> 5. You only need one build per project |
| **👎 Cons** | 1. Without modifying the build process template, the build will deploy even if the unit tests fail<br /> 2. To deploy a specific build to a particular server, it is necessary to get the code from source control, and then do a build<br /> 3. Only developers can deploy<br />4. You need a build per environment for each project<br /> 5. Build Once, Deploy Once. (You can't redeploy a build to a different environment) | 1. You must customize the build process template to execute the specified batch file from the build folder<br /> 2. We have to create custom batch files |
::: todo
**TODO:** AdamS - Include the steps to customize the build process template.
:::
Expand Down
Loading