Skip to main content

Delete/Redeploy Azure Websites at specific times within a TeamCity and Octopus Deploy CI/CD pipeline


Many clients request that specific environments be only available certain times during a day.

This is often due to the high cost associated with keeping environments that are not in use.

The problem here can be divided into two.

1. How do we make the environment unavailable?
2. How do we make the environment available once more?

Microsoft will charge Azure services per compute time. Meaning that even if you stop your Azure Website it will still incur costs. This is the crux of the problem. It means that we have to deploy and delete the deployment of the Websites in order to minimise cost effectively.

Now if we have our project building, testing and deploying in a TeamCity and Octopus deploy pipeline. Ideally the Undeploy and Re-Deploy should be tunneled through the appropriate stage in the pipeline.

The reason why we should do this is to ensure that redeployment goes through the same processes as a normal deployment, and that environment states (such as version number, failed/passed) all have one source of truth - The CI/CD pipeline.

A Solution

This solution assumes:
  1. That TeamCity is setup 
  2. Octopus Deploy is setup and deploying. Either with custom PowerShell scripts or the build-in Octopus ones.
There are three steps to the solution which I will show below.
  1. Write a PowerShell script that calls the Octopus REST API that simply re-deploys the latest release.
  2. Write a PowerShell script that deletes the deployment on the environments.
  3. Set triggers on TeamCity and call these scripts.

Step 1 - Deploy script

I assume that you've already got Octopus deploying successfully.

The next step is to create a PowerShell script that calls the Octopus API and deploys your application from Octopus. The logic is:
  1. Find the environment
  2. Get the current deployed release on that specific environment
  3. Redeploy this release
An example of this script can be found here.

Basically this script 'redeploys' the latest release on a given environment. The reason why we have parametised the environment is that many organisations have more that one testing environment they need taken down during non-operational hours.

Step 2 - Undeploy/delete script

As I stated previously, we need to actually delete an environment in this case, because of the way Azure has priced its services.

We opted to use the Azure cmdlets to do this. An example can be found here.

Step 3 - TeamCity triggers

Now, the final step is to setup your TeamCity triggers to execute the above scripts at the appropriate times.

Typically, the deploy script (from step 1) will be executed in the morning and the updeploy/delete script (from step 2) will be executed in the evening.

What I prefer doing is having two build configurations for each of the above. A deploy configuration and an undeploy.

Setup each of the build configuration. Then go to build steps and add the powershell script.

Then go to triggers and add a 'schedule trigger'.

And that's it! You're done.


1. Create deploy script using Octopus API.
2. Create delete deployment script using Azure cmdlets.
3. Use TC as script runner and schedule scripts.


  1. Thanks for sharing, nice post!

    Casanova là quán cafe tphcm được thiết kế hoàn toàn theo phong cách độc đáo của nước Ý, đây là quán quán cà phê cổ ở sài gòn không gian cổ điển đẹp hay cách thưởng thức cafe capuchino hay cafe dep o sai gon với không gian tuyệt đẹp hay bạn có biết loi ich ca phe đối với sức khỏe chưa quán cà phê làm việc lý tưởng của freelancer hay quán cafe chụp ảnh đẹp hay đây là cafe con hẻm nhỏ hay đây là quán cafe học nhóm tphcm cực hợp có phòng riêng hay quán cafe tình nhân ở sài gòn hay đây là 1 trong quán cafe lãng mạn sài gòn với đồ uống giá rẻ hay là điểm hẹn cà phê cuối tuần với Casanova Cafe hay meo giup be ngu ngon giúp bé ngủ ngon giấc hay nôi võng giúp bé ngủ ngon.


Post a Comment

Popular posts from this blog

from zero to production in eighty days

When I mean zero, I literally mean zero. A brand new project, a PO that's new to IT, no existing processes in place and a small team of four including myself and the PO.

The departmental organisation we were working for doesn't have any developers, scrum masters, product owners working for them. Everything they did was either done by another department or outsourced completely.

This is a story how we went from zero to production in eighty days.

My first time speaking at a conference

Since time immemorial we humans have valued the art of public speaking. Today, I want to share with you my experiences in speaking at conferences for the first time. Recently, I spoke at both DDD Melbourne and DDD Perth. Both of which were positive experiences that I learnt a lot in.

Have You Ever Produced Negative Value in a System!?

As developers we encourage our product owners to order the priority of their backlog in order of value. However, every time a new feature is implemented by a development team, there is a certain degree of risk associated with the introduction of that new code. Namely, risk of breaking another part of the product and maintenance cost. When a development team pulls in a new feature to implement there is a certain acceptance of this risk. In many cases, the risks that arise due to additional code complexity doesn't justify the value added by the new feature itself, so the development team can start implementing it.

Are there scenarios where the value added to a software product can be negative though?