Merge pull request #2028 from OctopusDeploy/sf/title-sentence-casing

Single pass through headings to fix casing

src/pages/docs/administration/high-availability/design/octopus-for-high-availability-on-gcp.mdx

@@ -1,7 +1,7 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2023-01-01
-modDate: 2023-01-01
+modDate: 2023-10-04
 title: Designing Octopus HA in GCP
 description: Information on configuring Octopus High Availability hosted in Google Cloud Platform (GCP).
 navOrder: 40
@@ -345,7 +345,7 @@ Once you've completed those steps, [install Octopus](/docs/installation/) and th
 Changing the path only needs to be done once, and not on each node as the values are stored in the database.
 :::
 
-### Load Balancing in Google Cloud
+### Load balancing in Google Cloud
 
 To distribute traffic to the Octopus web portal on multiple nodes, you need to use a load balancer. Google Cloud provides two options you should consider to distribute HTTP/HTTPS traffic to your Compute Engine instances.
 

src/pages/docs/administration/high-availability/index.md

@@ -1,7 +1,7 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2023-01-01
-modDate: 2023-08-24
+modDate: 2023-10-04
 title: High Availability
 description: Octopus High Availability (HA) enables you to run multiple Octopus Server nodes, distributing load and tasks between them.
 hideInThisSection: true
@@ -42,7 +42,7 @@ The node limit is included in the license key in the NodeLimit node.
 
 If you do not have that node in your license key then you are limited to a single node.  If you recently purchased a license key and it is missing that node then reach out to [[email protected]](mailto:[email protected]).
 
-## How High Availablity Works
+## How High Availablity works
 
 In broad terms, HA allows for load to be distributed between multiple Octopus Server nodes.  How that load is distributed, specifically tasks, is more complex than "it's load balanced."
 

src/pages/docs/administration/high-availability/migrate/index.mdx

@@ -1,7 +1,7 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2023-01-01
-modDate: 2023-01-01
+modDate: 2023-10-04
 title: Migration
 description: How to migrate from a stand-alone Octopus server to a High Availability (HA) setup.
 navOrder: 30
@@ -102,7 +102,7 @@ The advantage of a new URL is:
 
 <LoadBalancerEndpointInfo />
 
-## Outage Windows
+## Outage windows
 
 The below steps will cause an outage in Octopus Deploy.  With all the prep work, the outage window should be small.  If possible, we recommend making these change off-hours.  In addition, you don't have to do them all in one outage window.  You can move the database in one outage window, and the file system in the other outage window.  
 
@@ -161,7 +161,7 @@ After you finish moving the database and file storage, it is time to turn back o
 1. Assuming all goes well, disable maintenance mode.
 1. Notify everyone of the new URL (if there is one).
 
-## Adding Additional Nodes
+## Adding additional nodes
 
 After configuring a load balancer and moving the database and files, adding a new node is trivial.  
 

src/pages/docs/administration/managing-infrastructure/lost-master-key.md

@@ -1,7 +1,7 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2023-01-01
-modDate: 2023-01-01
+modDate: 2023-10-04
 title: Recovering after losing your Octopus Server and Master Key
 description: A guide to recovering if the machine hosting Octopus Server dies irrecoverably, and you don't have the Master Key.
 navOrder: 40
@@ -24,7 +24,7 @@ Octopus [encrypts important and sensitive data](/docs/security/data-encryption)
 - Sensitive values in your deployment processes, like the password for a custom IIS App Pool user account.
 - Sensitive values in your deployment targets, like the password for creating [Offline Drops](/docs/infrastructure/deployment-targets/offline-package-drop).
 
-## Recovering with a New Master Key
+## Recovering with a new Master Key
 
 If you are confident with Octopus you can follow these steps to get back up and going. Otherwise, please get in contact with our [support team](https://octopus.com/support) so we can be available to help get you up and going.
 

src/pages/docs/administration/managing-infrastructure/performance/index.mdx

@@ -1,7 +1,7 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2023-01-01
-modDate: 2023-01-01
+modDate: 2023-10-04
 title: Performance
 description: Octopus is all about reliable and repeatable deployments, but that doesn't mean it has to be slow. This page will help you tune your Octopus installation for the best performance in your scenario.
 navOrder: 60
@@ -136,31 +136,31 @@ Delta compression doesn't always result in smaller package transfers.  The algor
 
 If your packages have a lot of static data, consider creating a package containing only that static data and deploying it only when it changes.  
 
-### Custom Package Feed
+### Custom package feed
 
 Consider using a custom package feed close to your deployment targets, and download the packages directly on the agent. This alleviates a lot of resource contention on the Octopus Server.
 
-### Retention Policy
+### Retention policy
 
 The built-in package feed has its own [retention policy](/docs/administration/retention-policies/#set-builtinfeed-retentionpolicy).  Ensure that is enabled to keep the amount of packages to store and index down.
 
 :::div{.hint}
 The package retention policy only deletes packages not referenced by a release or runbook.  Setting the retention policy to 1 day means the package will be deleted 1 day after the release is deleted.
 :::
 
-## File Storage 
+## File storage 
 
 Octopus Deploy stores BLOB data (task logs, packages, project images, etc.) on the file system.
 
-### Task Logs \{#tip-task-logs}
+### Task logs \{#tip-task-logs}
 
 Larger task logs put the entire Octopus pipeline under more pressure.  The task log has to be transferred from the Tentacle to the server, it has to be saved to the file system, and is read when you are on the deployment or runbook screen.  We recommend printing messages required to understand progress and deployment failures. The rest of the information should be streamed to a file, then published as a deployment [artifact](/docs/projects/deployment-process/artifacts).
 
-### Image Size
+### Image size
 
 While it is fun to have gifs and fancy images for your projects consider the size of each image.  Keep them under 100x100 pixels.  This will reduce the amount of data you have to download from the Octopus Server. 
 
-## Deployment Parallelism
+## Deployment parallelism
 
 By default, Octopus will only run one process on each [deployment target](/docs/infrastructure/deployment-targets) at a time, queuing the rest. There may be times that you want to run multiple processes at a time. In those situations, there are three special variables that can be used to control the way Octopus runs steps in parallel:
 

src/pages/docs/administration/managing-infrastructure/server-configuration-and-file-storage/manually-uninstall-octopus-server.md

@@ -1,15 +1,15 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2023-01-01
-modDate: 2023-01-01
+modDate: 2023-10-04
 title: Manually uninstall Octopus Server
 description: Information on how to manually uninstall the Octopus Server.
 navOrder: 1
 ---
 
 When you uninstall the Octopus Server MSI, it automatically removes the application files from the installation folder, but that's it. This page describes how to manually clean up Octopus Server in part, or completely remove it from your server.
 
-## Why Would I Want To Clean Up? {#ManuallyuninstallOctopusServer-WhywouldIwanttocleanupinthefirstplace?}
+## Why would I want to clean up? {#ManuallyuninstallOctopusServer-WhywouldIwanttocleanupinthefirstplace?}
 
 :::div{.problem}
 

src/pages/docs/administration/retention-policies/index.mdx

@@ -1,7 +1,7 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2023-01-01
-modDate: 2023-01-01
+modDate: 2023-10-04
 title: Retention policies
 description: Retention policies allow you to specify the releases, packages and files you want to keep as well as the ones you want cleaned up.
 navOrder: 70
@@ -204,7 +204,7 @@ Choosing the *A limited time* option will allow you to select the number of days
 Only packages that are not associated with releases will be cleaned up. That means even if a package is older than the value you choose, if it's attached to an existing release, it won't be cleaned up until that release is also cleaned up.
 :::
 
-## External Feeds
+## External feeds
 
 Octopus does not apply any retention policies to external feeds. However the packages that are currently in-use can be retrieved from the API ([example](https://github.com/OctopusDeploy/OctopusDeploy-Api/blob/master/Octopus.Client/LINQPad/GetInUsePackages.linq)) and those results then used to remove packages from those feeds.
 

src/pages/docs/administration/sync-instances/index.md

@@ -1,7 +1,7 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2023-01-01
-modDate: 2023-01-01
+modDate: 2023-10-04
 title: Sync multiple instances
 description: How to keep two or more Octopus Deploy instances in sync.
 navOrder: 45
@@ -17,7 +17,7 @@ Keeping multiple instances in sync is a complex task involving dozens if not hun
 TL;DR; copying projects between instances should be done when all other options have been exhausted.  There is no provided tooling to support syncing instances with different environments, tenants, or variable values.  Due to the number of decisions and business rules, you will have to create and maintain a custom syncing process.  Before making this decision, reach out to [[email protected]](mailto:[email protected]) to see if there are alternatives.
 :::
 
-## Suitable Scenarios
+## Suitable scenarios
 
 Split and sync instances only when Octopus lacks a critical feature to satisfy a company policy, industry regulation, or a business contract.  The use cases we've seen in the past are:
 
@@ -104,7 +104,7 @@ We make that recommendation because, as you'll soon see, there are a lot of busi
 
 The Octopus team has written a sample PowerShell tool, [SpaceCloner](https://github.com/OctopusDeployLabs/SpaceCloner), you can use as a reference or example for your syncing process.  A lot of this documentation used lessons from writing that tool.  While the SpaceCloner supports syncing instances with a known delta, we recommend using that tool as a guide.  It was created with specific use cases in mind and probably won't support your hyper-specific use case.
 
-## Syncing Process
+## Syncing process
 
 If you do determine the best course of action is to sync projects across multiple Octopus Deploy instances, then you will need to start designing a syncing process.  While the actual business rules and decisions will vary between implementations, the core rules for any syncing process will remain the same.
 
@@ -130,7 +130,7 @@ It will be nearly impossible to know which instance is "right" and whether the c
 
 It's okay to have known differences between the instances, such as different environments, lifecycles, variable values, tenants, deployment targets, channels, and more.  But when something new is added, such as a new variable or step, it should be done on one instance and synced to the other instance.  It is hard enough to detect when something is "new". A one-way sync will help keep conflicts to a minimum, and reduce complexity.
 
-### Data to Sync
+### Data to sync
 
 Octopus Deploy is more than a deployment process and variables.  A lot of scaffolding data is needed for everything to work correctly.  The syncing process should allow for the syncing of the following data:
 
@@ -258,7 +258,7 @@ A deployment, and runbook run, have the same limitation.  Issuing a `POST` comma
 
 What this comes back to is auditability.  If that data can be modified by any outside process then it is not auditable.
 
-### Syncing Order
+### Syncing order
 
 In our experience, it is far easier to group data by type and sync them all together.  For example, sync all the Project Groups before syncing Projects.  That requires an order of precedence in syncing due to data dependencies.  That order of precedence is:
 
@@ -383,7 +383,7 @@ In most cases, it doesn't make much sense to sync Accounts and Certificates.  Bu
 - Create an Account or Certificate with the same name on each instance but different details.  You don't have to modify any variables.
 - Re-use the same variable name but associate it to different Accounts or Certificates.  The syncing process will only create new variables and insert dummy data.
 
-### Variable Scoping
+### Variable scoping
 Syncing variables between instances with different environments is very complex due to scoping and variable types.
 
 For all the examples below, the source instance has **Development** and **Test** while the destination instance has **Staging** and **Production**.  The source instance has the following variables.
@@ -493,7 +493,7 @@ Both Accounts and Certificates are referenced by variables in either projects or
 
 In most cases, it doesn't make much sense to sync Accounts and Certificates.  But the variables referencing the Accounts and Certificates are used in Deployment and Runbook processes.  In this case, the best option is to re-use the same variable name but associate it with different Accounts or Certificates.
 
-### Team User Role Scoping
+### Team User Role scoping
 
 The Team user role scoping is used for permissions.  For example, a team has access to edit a specific set of Tenants.  In this case, it makes sense to exclude any Tenants not found on the destination instance from the team user role scope.  It won't hurt anything as that Tenant doesn't exist.  Most likely, the list of Tenants that particular team has permission to edit will be very different.
 

src/pages/docs/administration/upgrading/guide/automate-upgrades.mdx

@@ -1,7 +1,7 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2023-01-01
-modDate: 2023-07-10
+modDate: 2023-10-04
 title: How to automate Octopus Deploy upgrades
 description: A how-to guide on how to automate Octopus Deploy upgrades
 navOrder: 4
@@ -14,7 +14,7 @@ Automating the Octopus Deploy upgrade ensures all essential steps are executed d
 
 This guide was written for upgrading Octopus Deploy on Windows. 
 
-## Prep Work
+## Prep work
 
 Before going down the automation path, it is critical to back up the master key and license key.  If anything goes wrong, you might need these keys to do a restore.  It is better to have the backup and not need it than need the backup and not have it.  The master key doesn't change, while your license key changes, at most, once a year.  Back them up once to a secure location and move on.
 
@@ -23,7 +23,7 @@ Before going down the automation path, it is critical to back up the master key
 
 <OctopusBackupMasterKey />
 
-## Upgrading Single Node Octopus Deploy instances
+## Upgrading single node Octopus Deploy instances
 
 A single node Octopus Deploy instance is an instance not configured for [high availability](/docs/administration/high-availability).  The instance is running on a single Windows Server, and as such, you can run this script to:
 

src/pages/docs/administration/upgrading/guide/index.md

@@ -1,15 +1,15 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2023-01-01
-modDate: 2023-01-01
+modDate: 2023-10-04
 title: Upgrading a modern version of Octopus
 description: Everything you need to know about upgrading a modern version of Octopus.
 navOrder: 1
 ---
 
 A modern version of Octopus Deploy is any version running on SQL Server.  When Octopus Deploy was originally introduced, it ran on RavenDB.  Octopus Deploy 3.x migrated from RavenDB to Microsoft SQL Server.  This section contains guides to covering various use cases you might encounter when upgrading a modern version of Octopus Deploy.
 
-## Upgrade Scenarios
+## Upgrade scenarios
 
 The default upgrade scenario is an in-place upgrade.  Thousands of customers upgrade every month without errors.  However, no upgrade process is ever 100% error-free 100% of the time.  The typical errors we see are:
 
@@ -25,7 +25,7 @@ Please choose from one of five common upgrade scenarios:
 - [Upgrading from Octopus 3.x to latest version](/docs/administration/upgrading/guide/upgrading-from-octopus-3.x-to-modern)
 - [Upgrading host OS or .NET version](/docs/administration/upgrading/guide/upgrade-host-os-or-net)
 
-## Mitigating Risk
+## Mitigating risk
 
 The best way to mitigate risk is to automate the upgrade and/or creating a test instance.  Automation ensures all steps, including backups, are followed for every upgrade.  A test instance allows you to test out upgrades and new features without affecting your main instance.
 

src/pages/docs/administration/upgrading/guide/upgrading-from-octopus-3.x-to-modern.mdx

@@ -1,7 +1,7 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2023-01-01
-modDate: 2023-01-01
+modDate: 2023-10-04
 title: Upgrading from Octopus 3.x to the latest version
 description: Information on how to upgrade from Octopus Deploy 3.x to the latest version
 navOrder: 6
@@ -37,7 +37,7 @@ You should be safe doing an in-place upgrade of 3.x to the latest version of Oct
 - Raised the [minimum requirements for hosting and using Octopus Server](https://octopus.com/blog/raising-minimum-requirements-for-octopus-server) (both Windows and SQL Server).
 - Execution containers running on docker on workers were introduced.
 
-## Prep Work
+## Prep work
 
 Before starting the upgrade, it is critical to back up the master key and license key.  If anything goes wrong, you might need these keys to do a restore.  It is better to have the backup and not need it than need the backup and not have it.  The master key doesn't change, while your license key changes, at most, once a year.  Back them up once to a secure location and move onto the next steps.
 

src/pages/docs/administration/upgrading/guide/upgrading-from-octopus-4.x-2018.x-to-modern.mdx

@@ -1,7 +1,7 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2023-01-01
-modDate: 2023-01-01
+modDate: 2023-10-04
 title: Upgrading from Octopus 4.x / 2018.x to latest version
 description: Information on how to upgrade from Octopus Deploy 4.x or 2018.x to the latest version
 navOrder: 5
@@ -34,7 +34,7 @@ It is generally safe to do an in-place upgrade from Octopus Deploy 4.x/2018.x to
 
 The upgrade should work without error, but there are integration concerns to consider.  This guide will step through the steps to mitigate those concerns.
 
-## Prep Work
+## Prep work
 
 Before starting the upgrade, it is critical to back up the master key and license key.  If anything goes wrong, you might need these keys to do a restore.  It is better to have the backup and not need it than need the backup and not have it.  The master key doesn't change, while your license key changes, at most, once a year.  Back them up once to a secure location and move onto the next steps.
 
@@ -160,7 +160,7 @@ Creating a clone of an existing instance involves:
 
 <UpgradeHighAvailability />
 
-## Rollback Failed Upgrade
+## Rollback failed upgrade
 
 While unlikely, an upgrade may fail.  It could fail on a database upgrade script, SQL Server version is no longer supported, license check validation, or plain old bad luck.  Depending on what failed, you have a decision to make.  If the cloned instance upgrade failed, it might make sense to start all over again.  Or, it might make sense to roll back to a previous version.  In either case, if you decide to roll back the process will be:
 

src/pages/docs/administration/upgrading/guide/upgrading-major-releases.mdx

@@ -1,7 +1,7 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2023-01-01
-modDate: 2023-01-01
+modDate: 2023-10-04
 title: Upgrading major releases of Octopus Deploy
 description: Information on how to upgrade major releases of Octopus Deploy.
 navOrder: 3
@@ -36,7 +36,7 @@ In general, the process looks like this:
 
 Learn more about [creating a test instance](/docs/administration/upgrading/guide/creating-test-instance).
 
-## Prep Work
+## Prep work
 
 Before starting the upgrade, it is critical to back up the master key and license key.  If anything goes wrong, you might need these keys to do a restore.  It is better to have the backup and not need it than need the backup and not have it.  The master key doesn't change, while your license key changes, at most, once a year.  Back them up once to a secure location and move onto the standard upgrade process.