City Hall Setting Server

City Hall is a tool to help organizations manage settings. This means giving everyone in the organization access to a set of tools which addresses their concerns. Business will want a simple website to administer settings for production, including things like an audit trail and permissioning. Quality assurance will want a way to maintain multiple versions of the settings simultaneously with the ability to easily switch between sets of related permissions. And, finally, development will want a simple tool which will associate a human-readable string to a setting, regardless of the environment it is running on. City Hall is all of these things in one thin, light weight package.

Screenshots

	Settings are stored in a tree structure, and allow for user-specific overrides. Each user is given his specific override at runtime, and if that doesn't exist, the default. Settings are then duplicated across environments, which means that the development defaults and overrides can be different from the QA defaults and overrides, although they share the same path.
	The default viewer comes with a basic settings management: save values, mark private, create, delete, and audit. Likewise, you can use the default viewer to copy settings (and optionally all of their children) to different environments. This frees development from being responsible for settings management on systems they don't normally have access to, like production.
	The heart of the system is a lightweight set of users/permissions and environments. Anyone can create a user or an environment, and user permissions are set on a per-environment basis.

The Problem

Currently, there is no standardized way to do settings management. There are a few disjointed efforts, and they each have their own strengths and weaknesses. Mostly, companies have found a way to live with the lack of such a tool, and either relied on idiomatic, language-specific tools, or they've built and maintained their own from scratch.

The Problem In Action

Let's take, for example, three settings you might find a need to manage: A) a database connection string, B) a set of customers which are granted special privileges, C) settings for generating a daily report.

Solving it with Idiomatic Settings Files

Various languages have created settings files. Django has settings.py, Java has web.xml, C# has web.config, etc. These store key-value pairs, and are easily accessible at runtime.

Strengths

Such files are usually very easy to maintain. Because they are stored in source control, it is also easy to tell when they were modified, by whom, and thanks to commit-logs why.

Weaknesses

These files are plaintext, which means that giving users access to production settings might also give them access to protected information. Setting A above might have plain-text database password. They are also generally managed by the development team, which means that if business wants to change setting B and C above, they would have to talk to development. Moreover, seeing previous values is sometimes difficult.

Solving it with Purpose-Built Durable Storage

Another technique that users fall back on is to create a way to store these settings (usually a database table) and then create a business-facing tool to manage those settings. So, for example, setting B above might be a table with a customer id, a start date, and an end date. Setting C might be an XML storing the report settings.

Strengths

Since these are built by development, there is no practical limit on the robustness of this solution. They can maintain history, they can have audit trails, they can integrate with existing enterprise infrastructure.

Weaknesses

Of course, this puts the onus on development to create and maintain these tools. The more settings you have, the more different kind of storage is used to store them, the bigger the task of maintaining the tools become. If a company isn't careful, such work can take over the productivity of a department, as the product itself matures.

Solving it with Settings Managers

There are a few products out there which provide settings management, mostly in the form of key-value stores. Consul, ZooKeeper, Redis, Chef, etc. Values could be stored to such a tool, and the enterprise would then honor them from there.

Strengths

These tools are battle-tested, and are generally excellent at their job. They are usually lightning-fast, and very fault tolerant. In some specific cases, the eventual consistency of some of these products is a must.

Weaknesses

While these are great tools, they are generally not aimed at settings which might need to be managed by business. Generally, here, the emphasis is usually on speed, then on being distributed and/or consistency. None of these tools have an easy-to-digest, business-facing web page, and the use case where settings don't necessarily need speed or eventual consistency (but do need audit trails and permissions) isn't covered.

Solving it with City Hall

Here, City Hall has an answer to each of the sample settings. It introduces the concept of environment/key/value store, where each environment has essentially the same keys, but the values may differ. It supports users with read, read-protected, write, and grant permissions on a particular environment, and a simple web page to manage everything. It can work with your existing database, and your existing language, significantly cutting down on the technical debt you might incur. It has a strong audit trail for everything that happens to a key. It moves management of business settings into the hands of business.

Database connection would be stored with a known key, but would be protected (requiring elevated read permissions) in the case of sensitive database passwords.

List of Customers would be stored as a comma-separated list. Since different environments would all have the same key, development can modify the list at runtime in the dev environment without worrying about accidentally having it wind up in production.

Report Settings would be stored as children of a known key. Business can add and remove these in production without having to ask development for any special work. This is essentially gives you the strengths of purpose-built web page, for free, without actually needing to do this work yourself.

Stack independent

City Hall strives to be as stack independent as possible, in order to be easily inserted into any enterprise or workflow.

The server itself is open-sourced on github and written in Python Django. This makes it OS and SQL server independent. It also, should the need arise, makes it very easy and quick to extend. The server can also be quickly be deployed to Heroku if you require a fast evaluation environment.

There is a native Python library, available on PyPi. The code for the library is distributed under MIT license on github.

There is a native Node.js library, available on npm. The code for the library is distributed under the MIT license on github.

There is a native Angular library, availabe on bower. The code for the library is distributed under the MIT license on github.

There is a library for Go on github distributed under the MIT license.

There is a native C# library, available on NuGet. The code for the library is distributed under the MIT license on github.

There is a native Java library, available on maven. The code for the library is distributed under the MIT license on github.

For questions about custom work including training and enterprise installations, please reach out to alex.popa at digitalborderlands.com