EngineeringProductivity/Projects/Conduit/Tech Stack: Difference between revisions

EngineeringProductivity/Projects/Conduit/Tech Stack (view source)

1,227 bytes added , 20 September 2017

→‎Conceptual Choices: no synchronized deployments

Confirmed users

1,927

edits

@@ Line 76: / Line 76: @@
 === RESTful ===
+=== No Synchronized Deployments ===
+Conduit is made up of a number of services, some large (BMO, Phabricator), some small (lando-ui, lando-api).  Each of these services communicates with at least one of the others.  Thus, there are occasions in which modifications to two (or more) services are necessary to fix an issue or implement a new feature.
+In these cases, it is important to carefully plan the changes to '''''not''''' require synchronized deployments. Especially in the case of the larger applications, timing deployments can be difficult, and there always exists the possibility that one service will have to be rolled back, further complicating the situation.  Instead, changes should be designed to be backwards compatible, such that they can exist on one system before the associated change is rolled out to the other.  Versioned APIs would make this easiest, but in other cases simple checks like the absence or presence of a particular key in a request or response is sufficient.
+Ideally, in the case of a change to two systems, both will be backwards compatible, but we may be able to get away with only having one be fully compatible if there exists a reasonable certainty that it will be deployed first.