Since a GrainService runs on the silo from startup to shutdown, what is the best strategy to deploy a new version on the same cluster?
We do not deploy a new version of a GrainService on its own. What we do is we redeploy the entire cluster, silo by silo, with new versions of all grains and other code. This is often done in either a rolling deployment fashion or a blue-green deployment fashion from your automated DevOps build and release schedule. This is the same strategy as you'd use to roll out a regular ASP.NET web site, there's nothing special about it.
If you're looking for hot code swapping in Erlang style, that is not supported at this time, AFAIK. With containerized micro-services hosts such as Service Fabric and Kubernetes making automated rolling deployments and rollbacks easier, I'm not sure it ever will for lack of need.
Most helpful comment
We do not deploy a new version of a
GrainServiceon its own. What we do is we redeploy the entire cluster, silo by silo, with new versions of all grains and other code. This is often done in either a rolling deployment fashion or a blue-green deployment fashion from your automated DevOps build and release schedule. This is the same strategy as you'd use to roll out a regular ASP.NET web site, there's nothing special about it.If you're looking for hot code swapping in Erlang style, that is not supported at this time, AFAIK. With containerized micro-services hosts such as Service Fabric and Kubernetes making automated rolling deployments and rollbacks easier, I'm not sure it ever will for lack of need.