<p>The absolute first change in your process I would make is to add the files to source control. Maintaining the scripts in version control is probably your highest priority as this should be your main source of truth for your database scripts. I would add these scripts to source control before you run them. Then, having some type of cron job, ADO pipeline, etc. that downloads these files and pushes to source control is crucial.</p>
<blockquote>
<p>My concern is the analyst would get confused on how to create a pull
request in GitHub.</p>
</blockquote>
<p>It sounds like there are a lot of technical limitations to overcome here. Whether that is knowledge or boundaries elsewhere, I would say automating as much as you can to remove human error is the next step forward. Creating an ADO pipeline to run your deployments (even if having to be executed manually) is a great start.</p>
<blockquote>
<p>These code changes almost happen daily and take a chunk of my time every day. Or am I just wasting my time trying to come up with
something that doesn't might not have much value?</p>
</blockquote>
<p>I think you've answered your own question :) If this is a sizable chunk of your time daily, it's easily worth your time and effort to automate this workflow and make it more reliable. You will save hours a week and reduce the number of mistakes caused by repeating these manual deployments.</p>

CC BY-SA 4.0
2024-03-04T19:25:29.403Z
2024-03-04T19:59:07.790Z
2024-03-04T19:59:07.790Z
Preston Martin
<p>A vendor is supplying one-off &quot;hot fixes&quot; and I am trying to streamline these deployments best I can. Currently I am going out to an FTP site, downloading the SQL scripts and manually deploying them against the various database environments. A few items to note:</p>
<ol>
<li>Often these SQL scripts have to be executed against the database in a particular order according to the vendor, however this has caused problems in the past as sometimes manual deployments have led to errors as they were not executed in the correct order.</li>
<li>It is not given that these deployments will make it to production, often times deployments are not successful and redo scripts are then supplied from the vendor, effectively making these deployments throw away deployments.</li>
<li>I don't think there is an internal repo or CI/CD practice in place, as the belief is that this is the job of the vendor.</li>
<li>I would like to capture the output from each execution and send it to a MS Teams channel for the analyst to know the status of the deployment. (Something I've done in the past)</li>
</ol>
<p>One thought was to create an Azure DevOps deployment and empowering the analyst to deploy these scripts when needed. My concern is the analyst would get confused on how to create a pull request in GitHub, so I'm not sure I can remove myself completely from the process as I probably would still have to download the scripts from the FTP site and drop them into GitHub and create the PR.</p>
<p>What can I do here to make this process easier and more reliant? These code changes almost happen daily and take a chunk of my time every day. Or am I just wasting my time trying to come up with something that doesn't might not have much value?</p>

<azure-devops><continuous-deployment><github><continuous-delivery><github-actions>
What would be the best approach or tool to deploy one-off SQL scripts?
Eric Swiggum
# What would be the best approach or tool to deploy one-off SQL scripts?

(Asked by: username_0 on 2024-03-04)

A vendor is supplying one-off "hot fixes" and I am trying to streamline these deployments best I can. Currently I am going out to an FTP site, downloading the SQL scripts and manually deploying them against the various database environments. A few items to note:

1. Often these SQL scripts have to be executed against the database in a particular order according to the vendor, however this has caused problems in the past as sometimes manual deployments have led to errors as they were not executed in the correct order.
2. It is not given that these deployments will make it to production, often times deployments are not successful and redo scripts are then supplied from the vendor, effectively making these deployments throw away deployments.
3. I don't think there is an internal repo or CI/CD practice in place, as the belief is that this is the job of the vendor.
4. I would like to capture the output from each execution and send it to a MS Teams channel for the analyst to know the status of the deployment. (Something I've done in the past)

One thought was to create an Azure DevOps deployment and empowering the analyst to deploy these scripts when needed. My concern is the analyst would get confused on how to create a pull request in GitHub, so I'm not sure I can remove myself completely from the process as I probably would still have to download the scripts from the FTP site and drop them into GitHub and create the PR.

What can I do here to make this process easier and more reliant? These code changes almost happen daily and take a chunk of my time every day. Or am I just wasting my time trying to come up with something that doesn't might not have much value?

**Tags:** azure-devops, continuous-deployment, github, continuous-delivery, github-actions


---

## 1 answers

### Answer by username_1 on 2024-03-04. Score: 2

The absolute first change in your process I would make is to add the files to source control. Maintaining the scripts in version control is probably your highest priority as this should be your main source of truth for your database scripts. I would add these scripts to source control before you run them. Then, having some type of cron job, ADO pipeline, etc. that downloads these files and pushes to source control is crucial.

> My concern is the analyst would get confused on how to create a pull
> request in GitHub.

It sounds like there are a lot of technical limitations to overcome here. Whether that is knowledge or boundaries elsewhere, I would say automating as much as you can to remove human error is the next step forward. Creating an ADO pipeline to run your deployments (even if having to be executed manually) is a great start.

> These code changes almost happen daily and take a chunk of my time every day. Or am I just wasting my time trying to come up with
> something that doesn't might not have much value?

I think you've answered your own question :) If this is a sizable chunk of your time daily, it's easily worth your time and effort to automate this workflow and make it more reliable. You will save hours a week and reduce the number of mistakes caused by repeating these manual deployments.


---

