Dynamically Scheduled build

Hello C Kohl,

Looks like your workflow boils down to these points:

1. Scheduling a build in TeamCity, which can be done by configuring a schedule trigger in TeamCity that will automatically start your deployment at the time specified. Scheduling deployment for off-peak hours can reduce the impact of the possible downtime and other inconveniences for your customers.

2. Sending out a notification, which is trickier: currently there is no straightforward way to configure TeamCity to send out a notification when you schedule a build. However, you might find it useful to notify customers when a build starts (the details of events triggering notifications are available here), especially if your deployment is scheduled for off-peak hours.

3. Customizing TeamCity notifications texts, which can be done as described in this section in our documentation. 

Hope that helps.

Julia

Hello Julia,

thank you very much for your reply.

1. I know about these trigger options but my request more points for a dynamic scheduled build, not a scheduled repeating deployment. I would like to be able to do both - dynamic scheduled builds and fixed "repeating" deployments. Trigger a deployment in off peak hours isn't possible, because a deployment also includes manual tests. The websites I'm aiming for this workflow have up to 1,5 million visitors a month, that's why it's really necessary to complete automated tests during deployment and manual tests after it.

2. Ok, thanks.

3. Yes, I know. Trank you!

I would like to know if these option may be interesting for TeamCity in general? I think dynamic scheduled builds and a notification when scheduling a build might also be interesting for other people?

Best regards

Hello C Kohl,

Thanks you for clarification. I just wanted to note that besides repeated builds, the schedule trigger allows scheduling a build for a specific date and time: just select 'advanced (cron expression)' in the when drop-down.

As to sending emails to customers, TeamCity notifications may not be what you want, as any user can unsubscribe from them. 

Here is a way you might consider:

Let's assume you want to inform your customers on the upcoming deployment 15 min before it starts.

Create a build configuration with 3 steps:

1. This step runs your own script sending out emails to your customers.

2. This step does nothing but waits for 15 min. (This delay can be added to your script in the previous step).

3. This step triggers deployment.

Add a schedule trigger set to 15 min before the desired deployment time: it will trigger a build and your customers will be notified prior to deployment.
For a repeated deployment, add another trigger and schedule a regular time.

Do you think this can be useful for your workflow?

Hello Julia,

yes, that's the approach I also had in mind. In this case the build agent would be blocked for 15 minutes and for several projects this could cause some trouble. We have a license for 3 build agents in our company and blocking a build agent 15 minutes (for nothing - just a delay) could raise our costs for TeamCity. That's why I hoped there is any other solution. Unfortunately, there is no such build in solution in TeamCity.

I would like to know if my workflow maybe would be also interesting for your other customers and thinking about adding any solution to the TeamCity core?

C Kohl,

Thank you for your feedback.

Perhaps another thing you could try is enable Versioned settings for your deployment project. When you change the schedule trigger for your deployment (setting it for 15 min prior the deploy), TeamCity will commit this modification to the VCS.

Another build configuration could be looking at this VCS root with settings, and on detecting a change in the version control it could fire a build sending out an email to the customers from the script.

This approach will free the build agent, but the downside is that when your deployment build is triggered on schedule, it may wait in the build queue if the compatible build agents are busy - the actual deployment will run later than scheduled.

Please let me know if this approach works better for you.

If you have a suggestion for TeamCity functionality, could you kindly create an issue describing what the new feature will do?  Please add it to our tracker (click on "Create Issue" on the top):  other users will be able to vote for it too and you'll be notified on any progress with your request.

Hello Julia,

again - thank you very much for your efforts but sadly this also isn't the best approach for us.

We only use the VCS trigger options for the staging area because we setup different groups, roles and rights in our TeamCity environment. With a VCS trigger for the production environment everybody (who has VCS access) is able to trigger a deployment, but not everybody should be able.

Yes, I will create an issue for the tracker now.

Best regards

Here is the new tracker ticket -> https://youtrack.jetbrains.com/issue/TW-50295

C Kohl,

Sorry I could not be more helpful. Your feedback is really appreciated, thank you.