Deployment Strategy
A Deployment Strategy defines the conditions by which a Deployment Package should automatically be assembled and delivered to one or more Deployment Targets. A Deployment Strategy is a recipe that tells a listener within Cloud CMS how to identify nodes whose content has changed and should be deployed. It then describes what steps to take in terms of deploying the content.
If you're using Cloud CMS Publishing, you will not need to set up a Deployment Strategy by hand. The Publishing system will set one up for you when you add a Publication.
Source
Fundamentally, a Deployment Strategy defines the source of its content. Usually, this is a branch where content is changing and is being marked as DIRTY. Dirty content is far less exciting than it sounds. In this case, it's just content that is ready to be deployed.
To listen for any changes to content in a branch, you would set:
{
"source": {
"type": "branch",
"config": {
"branchRef": "branch://{platformId}/{repositoryId}/{branchId}"
}
}
}
Trigger
The next thing you need to do is describe how often the listener should trigger. This will either be IMMEDIATE
or SCHEDULED
. The former indicates that changes will deployed as they come in. The latter indicates that changes will deploy periodically.
Example:
{
"trigger": {
"type": "IMMEDIATE",
"config": {
}
}
}
Deployment Targets
You should then also indicate which Deployment Targets should be the recipients of the Deployment Packages once the strategy is triggered. These Deployment Targets contain configuration that is passed to their respective Deployment Handlers to upload content to S3, send it to an FTP server or copy it into a Cloud CMS branch.
{
"targetIds": [
"594d171fb1120a18f1f1",
"a18f194d1715120fb1f2",
"170fba162f18f15194d2"
]
}
Operation
Finally, you should indicate what kind of operation should execute. Either DEPLOY
or UNDEPLOY
.
{
"operation": "{operation}"
}