Janus (Change Management) - Accordance/accordance.github.io GitHub Wiki

Janus is a change tracking system. All the changes in the environments have to be recorded with Janus. Janus makes sure that the conflicting changes will not be happening at the same time. This is done via "Change/Deployment locks".

Reason: during the failure in the system, we, usually, look at the history to understand what change has happened recently in the environment. The bigger the change, the bigger the dependency matrix of the changes. The effect may be cascading. Solution: by reducing the change to a single component at a time on the dependency graph up and down the chain of dependencies, we can reduce the troubleshooting time. If there are no dependencies between the systems-under-change, there is almost no reason to stop the concurrent change to these systems.

In simple case the organization can make a decision to limit the change in the system to only "one change at a time". This is, although a simple solution, slows down the organizations’ velocity. The organization has to make a decision if that what it wants and, in many cases, it’s a reasonable way to reduce the impact of the change. If a failure has happened in the system, after the change has been implemented, it is very simple to attribute the failure to that change (if it was a single change in the system). If multiple changes has happened in the system before the failure, it’ll take more time for troubleshooting to narrow down the culprit change.

Accordance dependency graph helps to resolve some of these conflicts.

When a maintenance of a component is happening (let’s say "db1" is under maintenance), the system marks appropriate component to be "under maintenance". The same action is happening during a deploy of any application - an application is marked "under maintenance" at the beginning of the deploy and released after. This allows organizations to track changes in the system (which is implemented as an add-on Janus sub-system in the Accordance ecosystem).

The simple "maintenance locks" implementation allows to control what is deployed and in what order. The system looks at the "master locks" to deny any changes in the environments. It looks at the dependencies as well to deny changes up and down the graph branches that contains the component marked "under maintenance".

This simple mechanism allows to change independent components, but prevent concurrent change of the dependent ones. This way it’s becoming very easy to identify the culprit of the failure since only one change at a time is allowed by the system.