If you're using a different version approach you need to pay attention to this:
If the target parameter has been set for a job, the request is
sent to the specified version. Otherwise Cron requests are sent to the
default version of the application.
I've been using the target
parameter to direct cron jobs to different modules, based on the quote above I guess it could be used to direct jobs to different versions as well, using module routing via URL, probably something like this:
target: version
or
target: version-dot-module
Personally I prefer a different application approach to ensure no interference between the staging and the production environments, even when performing massive re-works breaking backwards compatibility :)
As for the method, I use 2 different workspaces from 2 different branches of the code, which have minimal differences between them (the application
fields in the .yaml
files and maybe other staging-related deltas):
- a
staging
workspace & branch
- a
production
workspace & branch
Whenever I'm happy with the code in the staging
branch I:
- merge the
staging
branch in the production
one
- update the
production
workspace and deploy from it -> updating the production
app
- disable whatever I need in the
staging
workspace (committing the changes to the staging
branch as well if so desired)
- deploy from the
staging
workspace -> updating the staging
app
Probably the method would be usable in a different version approach as well, the version
fields in the .yaml
files being different in the 2 branches.