Sometimes you've got code that you want to push to a group of servers. With the deploy code module you can not only pick as many servers as you want to push the code to, you can also pick the timeframe to deploy it. Here are the moving parts.
You can use this module to push out any code you need. For example, you need up update an SP on any group of boxes. Or you can push changes to jobs, or change DB properties, etc. The sky's the limit.
*While it's possible to push out code that changes data, like updates, we advise against this unless you can guarantee that it'll only alter a small number of rows. Currently, this is a single-threaded process and issuing large updates can greatly slow down the processing of all server code for a deployment window.
Tables
Deploy.Code - Holds all the info for the code to be deployed.
History.Code - Holds the history of each push with the status.
SPs
Deploy.CodeStmtsGet - Gets the list of code that needs to be deployed for the current timeframe.
Collector
CodeDeploy.exe - Gets the list of code to deploy and pushes it to all the servers.
Object Details
Deploy.Code
| Name | Data type | Nullable | Description |
|---|---|---|---|
| ID | bigint IDENTITY(1,1) | NOT NULL | |
| InsertDate | datetime | NULL | This is when the code was inserted into this table. |
| InstanceID | bigint | NULL | ID of the server to run the code against. |
| DBName | nvarchar(400) | NULL | Name of the DB to run the code in. |
| Category | nvarchar(100) | NULL | This isn't currently used by the system, but it is for the user to categorize their code to make it easier to query the table. |
| ScriptType | varchar(20) | NULL | Values: Direct|Disk. Direct means that the code itself resides in this table in the following Code column. Disk means that the code is in a script on the drive. |
| ScriptCode | nvarchar(max) | NULL | This is the code that you want to run. This is only valid when ScriptType = 'Direct' |
| ScriptPath | nvarchar(1000) | NULL | This is the full path and filename of the script to run. It must be available to the Minion server. Ex. C:\Scripts\NewJob.sql |
| BeginPushDate | date | NULL | The begin push date. See Deployment Windows below for more details. |
| BeginPushTime | time(0) | NULL | The begin push time. See Deployment Windows below for more details. |
| EndPushDate | date | NULL | The end push date. See Deployment Windows below for more details. |
| EndPushTime | time(0) | NULL | The end push time. See Deployment Windows below for more details. |
| Retries | smallint | NULL | The number of retries in case there's an issue. |
| RetryFrequencyMins | smallint | NULL | How many minutes between retries. |
| CurrentRetry | smallint | NULL | Which retry are you currently on? |
| GroupOrder | int | NULL | The operation order within a group. Used solely for determining the order in which code should be processed.
By default, all code has a value of 0, which means they’ll be processed in the order they’re queried.
Higher numbers have a greater “weight” (they have a higher priority), and will be processed earlier than lower numbers. We recommend leaving some space between assigned order numbers (e.g., 10, 20, 30) so there is room to move or insert rows in the ordering. |
| GroupCodeOrder | int | NULL | Group to which this code belongs. Used solely for determining the order in which code should be processed.
By default, all code have a value of 0, which means they’ll be processed in the order they’re queried.
Higher numbers have a greater “weight” (they have a higher priority), and will be processed earlier than lower numbers. |
| Push | bit | NULL | Values: 1|0. Whether to deploy or "push" the code. Using this setting, you can disable a push without losing the code itself. For more info, see Postponing Deployments below. |
Deployment Windows
Deployment windows are essential to a lot of our products. They allow you to get around a common issue with the SQL Agent: that of missed schedules. Let's say that you have code that you want to push at 22:00, then you come in the next day and find out someone was rebooting the server during that time. If you're pushing the code via SQL Agent, the code wouldn't be pushed because when Agent starts it'll check the time and see if there are any jobs that are meant to start at the current time. Well, if it's 22:10 and the job was supposed to start at 22:00, then the job will be skipped because it's past its start time.
However, with Minion's deployment windows, you specify a timeframe that you want the code to be deployed. Now let's use the same scenario above only now we'll use a deployment window. We want the code to be deployed at 22:00 So we setup a deployment window like this:
BeginPushDate = 2020-06-01
BeginPushTime = 22:00
EndPushDate = 2020-06-01
EndPushTime = 23:00
Now we have a 1-hr window in which the deployment can happen. So if the server is being rebooted at 22:00, then when it comes back up, it will see that it's 22:10, and it's still within the window, and it will deploy the code. This is a powerful feature that allows you to recover from simple operational situations.
Postponing Deployments
Let's say that you've inserted some code to deploy this weekend. Only now they're telling you that it needs to wait for a couple weeks. So instead of deleting the code out of the table, you can postpone in 2 ways.
First, you can change the date of the window. This is the easiest. If you have a solid date then yeah, go ahead and use this mechanism.
Second, you can set Push = 0. This will let you disable the deployment indefinitely. The best use case for this is when you don't know when the code will actually be deployed, but you don't want to delete it from the table.