Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scheduled deploys #476

Merged
merged 5 commits into from
Jan 19, 2018
Merged

Scheduled deploys #476

merged 5 commits into from
Jan 19, 2018

Conversation

sihil
Copy link
Contributor

@sihil sihil commented Jan 17, 2018

Pulled this together this afternoon with @nicl

This introduces scheduled deploys to Riff-Raff. This allows you to configure a project to deploy automatically according to a pre-determined schedule.

The aim of scheduled deploys is to have a mechanism for automatically updating AMIs even when a project is not actively being worked on.

Some details:

  • schedules are expressed as quartz cron expressions (as per AMIgo)
  • a scheduled deploy will re-deploy the most recent deploy to the specified stage
  • a scheduled deploy is skipped if there is no previous deploy or the most recent deploy failed or is still running

Possible future improvements:

  • only deploy if the most recent deploy was X days ago
  • something other than quartz crons for configuring

This is currently running and enabled in CODE.

Before merging:

After merging:

  • Add config scheduledDeployment.enabled=true in PROD
  • Remove config scheduledDeployment.enabled=true in CODE

Scheduling screen:
screen shot 2018-01-17 at 18 26 00

Deploy is run by a "scheduled deploy" user:
screen shot 2018-01-17 at 18 26 36

'_error -> configForm.globalError.map(_.withMessage("Please select deployment stage"))
)
@b3.text(configForm("schedule"), '_label -> "Schedule expression")
<p>This should be a weird Quartz cron expression
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Be good to give a (couple of) example(s) here. Most teams will be doing similar things and the docs are pretty dense.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. Think one is enough.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are a few traps we talked about here, which could happen by accident or deliberately:

  • people scheduling it too frequently
  • scheduling overnight/weekends
  • everyone scheduling at the same time

If the feature proves useful, we'll probably need to address some or all of these.

@davidfurey
Copy link
Member

I think it would be useful for this to default to excluding bank holidays. Avoiding Monday and Friday fixes for most, but there is still Christmas day, Boxing Day and New Years day.

Also, is the time UTC or Europe/London?

@sihil
Copy link
Contributor Author

sihil commented Jan 18, 2018

Bank holiday exclusions can certainly be added later if desired but isn't something I'm interested in for the first cut.

We should clarify the behaviour. My expectation would be that it is local time, but I suspect it relies on the default JVM timezone and is likely to be GMT.

@nicl
Copy link
Contributor

nicl commented Jan 18, 2018

@adamnfish @davidfurey this is a first pass so things like bank holiday etc. good to add once we know it's valuable.

We are going for a soft launch (i.e. probably not shouting about it at first). I'm planning on testing on Discussion once merged for a while as it's a good candidate project - several apps which hardly ever get deployed.

good question about timezone. I agree with @sihil let's check, but it's almost certainly GMT.

@sihil
Copy link
Contributor Author

sihil commented Jan 18, 2018

As guessed, Riff-Raff currently runs in UTC.

I've just pushed another commit that allows the user to explicitly select the timezone that the schedule should run in. It defaults to the timezone of the users browser (provided they have a reasonably modern browser).

When the quartz schedule is configured we provide the timezone. Seems to work based on a brief test in Kiev.

@sihil
Copy link
Contributor Author

sihil commented Jan 18, 2018

I think this is ready to ship. Would be glad of a review / 👍whenever someone has time.

@nicl
Copy link
Contributor

nicl commented Jan 18, 2018

@sihil I can 👍 but given we paired on it, another would also be good.

Copy link
Contributor

@TBonnin TBonnin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great job @sihil and @nicl
Code looks good

@sihil sihil merged commit 3133933 into master Jan 19, 2018
@sihil sihil deleted the sihil/scheduled-deploys branch January 19, 2018 10:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants