<p>I have an existing system that uses a relational DBMS. I am unable to use a NoSQL database for various internal reasons.</p>

<p>The system is to get some microservices that will be deployed using Kubernetes and Docker with the intention to do rolling upgrades to reduce downtime. The back end data layer will use the existing relational DBMS. The micro services will follow good practice and "own" their data store on the DBMS. The one big issue with this seems to be how to deal with managing the structure of the database across this. I have done my research:</p>

<ul>
<li><a href="https://blog.philipphauer.de/databases-challenge-continuous-delivery/" rel="nofollow noreferrer">https://blog.philipphauer.de/databases-challenge-continuous-delivery/</a></li>
<li><a href="http://www.grahambrooks.com/continuous%20delivery/continuous%20deployment/zero%20down-time/2013/08/29/zero-down-time-relational-databases.html" rel="nofollow noreferrer">http://www.grahambrooks.com/continuous%20delivery/continuous%20deployment/zero%20down-time/2013/08/29/zero-down-time-relational-databases.html</a></li>
<li><a href="http://blog.dixo.net/2015/02/blue-turquoise-green-deployment/" rel="nofollow noreferrer">http://blog.dixo.net/2015/02/blue-turquoise-green-deployment/</a></li>
<li><a href="https://spring.io/blog/2016/05/31/zero-downtime-deployment-with-a-database" rel="nofollow noreferrer">https://spring.io/blog/2016/05/31/zero-downtime-deployment-with-a-database</a></li>
<li><a href="https://www.rainforestqa.com/blog/2014-06-27-zero-downtime-database-migrations/" rel="nofollow noreferrer">https://www.rainforestqa.com/blog/2014-06-27-zero-downtime-database-migrations/</a></li>
</ul>

<p>All of the discussions seem to stop around the point of adding/removing columns and data migration. There is no discussion of how to manage stored procedures, views, triggers etc.</p>

<p>The application is written in .NET Full and .NET Core with Entity Framework as the ORM.</p>

<p>Has anyone got any insights on how to do continious delivery using a relational DBMS where it is a full production system? Is it back to the drawing board here? In as much that using a relational DBMS is "too hard" for rolling updates?</p>

<p>PS. Even though this is a continious delivery problem I have also tagged with Kubernetes and Docker as that will be the underlying tech in use for the orchestration/container side of things.</p>

TheEdge
<p>All of the following under the assumption that I understand correctly what you mean by "rolling updates" and what its consequences are.</p>

<p>It has very little (as in : nothing at all) to do with "relational DBMS".  Flatfiles holding XML will make you face the exact same problem.  Your "rolling update" will inevitably cause (hopefully brief) periods of time during which your server-side components (e.g. the db) must interact with "version 0" as well as with "version -1" of (the client-side components of) your system.</p>

<p>Here "compatibility theory" (*) steps in.  A "working system" is a system in which the set of offered services is a superset (perhaps a proper superset) of the set of required services.  So backward compatibility is guaranteed if "services offered" is never ever reduced <em>and</em> "services required" is never extended.  However, the latter is typically what always happens when the current "version 0" is moved to "-1" and a new "current version 0" is added to the mix.  So the conclusion is that "rolling updates" are theoretically doable as long as the "services" offered on server side are only ever extended, and always in such a way as to be, and always remain, a superset of the services required on (any version currently in use on) the client side.</p>

<p>"Services" here is to be interpreted as something very abstract.  It might refer to a guarantee to the effect that, say, if column X in this row of this table has value Y then I <em>will</em> find another row in that other table using a key computed such-and-so, and that other row might be guaranteed to have column values satisfying this-or-that condition.</p>

<p>If that "guarantee" is <em>introduced</em> as an <em>expectation</em> (i.e. requirement) on (new version of) client side, you must do something on server side to comply.  If that "guarantee" is <em>currently offered</em> but a <em>contradicting guarantee</em> is introduced as an expectation on (new version of) client side, then your rolling update scenario has by definition become inachievable.</p>

<p>(*) <a href="http://davidbau.com/archives/2003/12/01/theory_of_compatibility_part_1.html" rel="nofollow noreferrer">http://davidbau.com/archives/2003/12/01/theory_of_compatibility_part_1.html</a></p>

<p>There are also parts 2 and 3.</p>
