You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/pages/docs/deployments/azure/azure-environments.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -41,7 +41,7 @@ Once you have entered the environment name and endpoint values you should **Save
41
41
Whenever you are using an Azure step template, once you've selected an account its settings will be used to determine the endpoints for all of the API operations. So lists like Resource Groups and Web Apps will be loaded using the endpoints defined by the Account.
42
42
43
43
## Calamari and deployments
44
-
When a deployment executes, the values for the environment and endpoints will be passed to Calamari if they have been overridden (i.e. they aren't blank). You will be able to see the values if you have [OctopusPrintVariables set to true](/docs/support/debug-problems-with-octopus-variables/#DebugproblemswithOctopusvariables-Writethevariablestothedeploymentlog) and Calamari will also always log an information message to tell you if it's using overridden values and what they are.
44
+
When a deployment executes, the values for the environment and endpoints will be passed to Calamari if they have been overridden (i.e. they aren't blank). You will be able to see the values if you have [OctopusPrintVariables set to true](/docs/support/debug-problems-with-octopus-variables/#write-variables-to-deployment-log) and Calamari will also always log an information message to tell you if it's using overridden values and what they are.
Copy file name to clipboardExpand all lines: src/pages/docs/support/debug-problems-with-octopus-variables.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ navOrder: 1
9
9
10
10
Sometimes a variable used during deployment may have a different value from the one you expect. Here are the first steps to debugging these issues.
11
11
12
-
## Check the variable snapshot for the release {#DebugproblemswithOctopusvariables-ChecktheVariableSnapshotfortheRelease}
12
+
## Check the variable snapshot for the release {#check-variable-snapshot-for-release}
13
13
14
14
1. Open the **Project ➜ Releases ➜ Release** page for the Release you are debugging.
15
15
2. Scroll down to find the **Variables** section and click the **Show Snapshot** link so see the snapshot of Variables being used by this Release.
@@ -21,7 +21,7 @@ Sometimes a variable used during deployment may have a different value from the
21
21
22
22
:::
23
23
24
-
## Check the variable value in the all variables tab {#DebugproblemswithOctopusvariables-CheckthevariablevalueintheAllVariablestab}
24
+
## Check the variable value in the all variables tab {#check-variable-value-in-all-variables-tab}
25
25
26
26
1. Open the **Project ➜ Variables ➜ All Variables** tab.
27
27
2. Investigate the variables from all possible sources for the project including the project itself, [variable sets](/docs/projects/variables/library-variable-sets/), and [tenants](/docs/tenants).
@@ -34,7 +34,7 @@ Sometimes a variable used during deployment may have a different value from the
34
34
Did you know you can sort filter all of the variables grids? Click **Show Advanced filters** and select your filter type.
35
35
:::
36
36
37
-
## Write the variables to the deployment log {#DebugproblemswithOctopusvariables-Writethevariablestothedeploymentlog}
37
+
## Write the variables to the deployment log {#write-variables-to-deployment-log}
38
38
39
39
This will log the variables available at the beginning of each step in the deployment as Verbose messages.
@@ -32,7 +32,7 @@ Adding an image to your project is a useful way to set them apart from other pro
32
32
We have the three projects set up, but we need to share some common variables between them. The SQL Server that we are deploying to, the database name and the application name are variables that come to mind. To accomplish this, we are going to create a variable set for this specific application.
@@ -42,7 +42,7 @@ A project can reference 0 to N number of variable set. Variable naming is signi
42
42
It's also good to have a couple of other variable sets to handle some non-project specific values. For example, a global variable set that stores any infrastructure as code (or IaC) variables. The same naming convention applies as the project-specific variable set, for example, replacing **OctoFx** with **Global**.
Next, we are going to add the manual intervention step for the DBAs to approve. If you are configuring a fresh instance of Octopus Deploy, you may not have had the chance to configure a DBA team yet; that's okay. For now, just put in Octopus Administrators or a team that already exists. You can configure specific teams later.
@@ -68,7 +68,7 @@ This project deploys a database package using [DBUp](https://github.com/DbUp/),
68
68
Many [community step templates](https://library.octopus.com) have been created to help with some of this database scaffolding. We will use the **SQL - Create Database If Not Exists** step template to create the database if it doesn't exist. We are going to use variables from the variable set we included previously. For now, we are going to execute this script on a Tentacle with the role `OctoFX-DB.` Later in this guide, we will convert this to use workers.
There are a few more maintenance tasks to add, such as:
@@ -80,13 +80,13 @@ There are a few more maintenance tasks to add, such as:
80
80
Keep in mind, all of the steps being added are occurring before an actual deployment happens. Without doing a deployment yet, we have added in five steps to deploy the database. Imagine if this project also deploys a website, a Windows Service, and other components. The project would become very hard to manage.
Now we are ready to configure the database deployment. When creating a PoC or other deployment projects, you'll typically need to package up the database into either a NuGet or a Zip file. So far, in this guide, we haven't configured anything to push the packages to Octopus Deploy's internal package feed for it to deploy. However, the deploy a package step requires us to specify a package. The way we will short-circuit this chicken/egg scenario is by using variables. In a later chapter, we will worry about getting the packages uploaded, but we just want to set a variable for now.
Finally, the database deployment process is complete. The process is relatively simple; there might be some more approvals or additional steps you want to add. Again, the idea is to keep all the database deployment work in this specific project.
Don't spend too much time on the actual steps in the process. The major takeaways from this are that the database project is responsible for everything required to create, configure, and deploy a database. You might be using a different tool (like Redgate or RoundhousE) to do your deployments, which include some additional features.
@@ -114,25 +114,25 @@ Now it's time to move onto deploying the UI. Unlike the previous section, we wo
114
114
That being said, don't forget to include the variable sets in this particular project, just like you did with the database deployment project.
Below is the process we put together to deploy the web application. First, it gets approval from the web admins to do the deployment; then, it will do a rolling deploy across all the machines.
Next, we want to set the run condition on the manual intervention to look at the `Project.Approval.ManualInterventionRequired` variable. If it's set to `true`, that step will run, and if it's set to `false`, it will skip that step.
Let's repeat the same thing for the **OctoFX-WebUI** project; add the project variables `Project.Approval.ExternalApprover` and `Project.Approval.ManualInterventionRequired`, and the run condition on the manual intervention step.
That new icon appears because the start trigger has been configured to run in parallel with the previous step. This means you won't have to wait for a DBA to approve before the web admin approves it. The web admin can authorize the deployment, and then the DBA.
Now we can add in a deploy a release step for the **OctoFX-Database** project. Make a note of the variable being passed in. In this case, it is set to `false`. That means the manual intervention on the database project will be skipped (because it has already been approved by the time it gets here).
In a typical CI/CD setup, the database and web UI projects will automatically be deployed to the development environment by the build server. When should the traffic cop project be introduced? Not every database and web UI release will be promoted to a test environment. It's likely you won't be deploying both projects all the time, only some of the time. If the application were using something like Entity Framework without any stored procedures, then it could be entirely possible to have web UI changes, even for a major release.
205
205
206
206
Because of that, a unique lifecycle should be created for the traffic cop project. This lifecycle will skip the **Development** environment and start at **Test**.
This section's important takeaway is not necessarily the individual steps, but rather, some of the core concepts. We have a project which can coordinate the releases of other projects. Also, the approvals occur before the first deployment happens. Finally, we can have multiple approvals occur at the same time.
0 commit comments