How many times have you been in a situation where you are waiting for an important ci/cd pipeline delivery to finish only to find that it had failed with the error –
This happened to me for a few times and there were two usual approaches to resolution:
-request Data Center team for more disk space and immediately delete some folders to make code deploy successful
-create an automated process that ran periodically and deleted logs
The second option sounded interesting, provided I had time at hand. Ultimately, it came to such that creating an automated process would take less time than freeing up the disk space manually. That was the tipping point.
When it comes to automation, there are multiple ways of doing so and having used Azure Devops(aka TFS) for more than a decade, that was my goto orchestrator.
For example say we have more than a few dozen Dev/Test/QA boxes and its the C: drive that was getting filled up every once in a while with IIS Logs. To clear the logs files I had to create a release definition with below steps:
Step 1: Create a pipleline
Step 2: Add deployment group
Step 3: Add task
Step 4: Trigger release
Step1: This is where we name the individual environments where we want a task (or group of tasks) to be executed. Via pipeline, we orchestrate the deployment process.
In this case, the task that execute on Prod would have to be successful on PreProd; the task that execute on PreProd would have to be successful on QA and so forth all the way to Dev. This way we ensure that the process is well tested from environment to environment. Here is an image of pre-deployment condition for Test environment.
As can be seen, to deploy to Test, the deployment process had to be successful in Dev. After creating a pipeline, we move onto Deployment group (that is under Tasks tab)
Step2: Tasks tab shows a drop down arrow that lists all the environments that were added in the previous step.
Under each environment there is a default agent phase available. In our case we prefer a deployment group phase. Here we add the deployment groups that contain the names of the actual machines that belong to this group.
Step3: On the left hand pane we now search for Powershell and add that task.
The code to include inside Inline Script is included in the github link that I shared below.
Step4: Save the release definition and trigger a release
Now wait for magic!
As seen, the list of environments are available with the deployment status. One after the other as deployment to a particular environment succeeds, the next one gets picked up.
Bonus Item #1: Approval. Here in the above image you will see that there were no approvals necessary for Dev, Test and QA environments, but for PreProd there is an approval pending. That is because I put in a pre-deployment approval condition for that environment. The below image shows that option.
Once approval was provided, powershell command was executed on Preprod and Prod environment. We could have had an approval for Prod as well.
After the release definition was executed on all the environments, the deployment status ended with the below image.
Bonus Item #2: This release definition eliminated a need for me to manually delete logs files which was great, but I still had to trigger this. There is an option to schedule a release using which, we eliminate the need for manual trigger. Using scheduling the release definition will be auto-triggered which will then delete these log files at regular interval.
Github: DeleteIISLogs
My Devops Journal 