If you use a different version approach, you need to pay attention to this :
If the target parameter is specified for the job, the request is sent to the specified version. Otherwise, Cron requests are sent to the default version of the application.
I used the target parameter to set cron jobs for different modules based on the above quote. I assume that it can be used to direct jobs to different versions using module routing via URL , maybe something like this:
target: version
or
target: version-dot-module
Personally, I prefer a different application approach, so as not to interfere between the intermediate and the production environment, even when performing massive repetitive work that violates backward compatibility :)
As for the method, I use 2 different workspaces from two different code branches that have minimal differences between them ( application fields in .yaml files and, possibly, other delta-related steps):
- a
staging workspace and branch - a
production workspace and branch
Whenever I am satisfied with the code in the staging I branch:
- merge
staging branch into production one - update
production workspace and expand it -> update production application - disable everything I need in the
staging workspace (if you want to also make changes to the staging branch) - deployment from a
staging workspace -> updating a staging application
Probably, this method could be used in another variant, and the version fields in the .yaml files were different in two branches.
source share