Question: Is it possible to keep the old instances after a bg-deploy --no-confirm

[Kiemes]

We would like to keep the old instances after a blue-green deployment so that we can switch easily after we found an issue that was not found by the pipeline.

Looking at cf bg-deploy --help, there seems to be no option.
Wdyt? Would you consider adding such an option?

The community cf-cli plugin for blue-green deployments of native apps also supports this https://github.com/bluemixgaragelondon/cf-blue-green-deploy

[ddonchev]

Hi Kiemes,

For such cases, we recommend doing a new bg-deployment with the previous version of the solution. The complete state of the solution is not persisted only in the cf app entities. E.g. even if the routes get manually switch back to the former apps, the services and service bindings with their parameters won't get updated back to the previous values.
MTA deployment takes care to update such and brings the whole package to the state defined in the descriptor, which should be in the common case better tested & stable.

I understand that switching back only apps like this, though riskier in some cases, is much faster and may be of use. We're currently doing a change to the bg-deploy process - to switch back to the live-app names at the end of bg-deployment. After it's delivered (targeting Q1 2020), such a feature would be possible to implement as the old app versions would remain with an -old suffix and would be easily identifiable.

Even if this feature is to be implemented, one should consider doing a new deployment of the previous version for reasons as:

• the targeted state is more predictable, as described in the mtad.yaml of the deployed package
• the cf space would be left in a consistent state (no stopped apps from a new version, no mix with old apps & new service instance settings etc..)
• better traceability & auditability - one can trace the events of concrete deployments with their versions and solution state/configs.

[Kiemes]

Thanks @ddonchev for your comments. I was consciously asking for this and still having the risks in mind. Especially DB related changes are dangerous and have to be handled with care. But this also is true for the regular MTA deployments.

Thanks also for the hint about the new upcoming version. Are you planning to leave the -old app always there after a successful deployment or do you plan to have a flag to remove the -old app after deployment?

[ddonchev]

In the initial scope, the old apps will get deleted. I'm taking your feedback and will bring this to the team to consider an additional feature for preserving the apps.

[Kiemes]

thx. I am also fine with a global descriptor parameter ;)

[Kiemes]

A potential benefit of having an CLI parameter would be the easier handling in CI/CD pipelines. Here you would not need to modify the mtad.yml file or have multiple for the different use-cases.

[ddonchev]

I kind of started an off-topic about ui, but regardless - the idea of having parameters with defaults in the mtad.yaml is the ability to replace those defaults with extension descriptors (*.mtaext) at the teme of deployment. Creating those *.mtaext files is still more effortful than just specifying a cli option so the ui is decided on for each case.