YAML Config Editor Architecture

“Configuration as code” is a technique to store environmental variables, feature flags, and other configuration items in an SCM the same way the code is stored.   When the code is deployed,  the CI process generates the specific configuration for the proper environment from the config SCM.  Then the CD process deploys it to the appropriate hosts alongside the new code.   The significant advantage of this approach is that configuration changes are tracked over time which is critical to support.   

Our client desires to build a configuration tool that allows developers and DevOps a standard and hierarchical approach and intuitive  form like User Interface for managing and maintaining complex configuration environments.   This tool would be called by the DevOps pipeline to generate JSON configurations for deployment to environments.   Spring Cloud Config project will serve as inspiration for this project.  

In this challenge, we are building a yaml editor, which is hosted by a NodeJS server running in a docker container. When user requests the UI with an HTTP GET request from the browser the NodeJS server (HapiJS preferred) delivers the index.html and all static assets for the Angular application.  Once the application is running in the browser, the user wants to use it to edit some config files for user's deployed application. For this the user will need to give a git repo url and login credentials. The app would then send a message back to the NodeJS server to perform a shallow clone (we do not need history here) from the git origin (much the same that Jenkins does when it builds your source code).
Once the repo is cloned the nodejs server can deliver a file list to the browser (only YAML files are delivered, the other files are ignored). The app can either select  a file to edit, create a new one, or remove a file. The server either reads (or creates a new file) and sends the content to the browser. And we only need to work with files in the root directory of git repo, no need to support folder for now. 

The app should not work on the master branch of the git repo, it should work on a default 'admin' branch. 

The app then parses the content and allows the user to edit/create properties within the default block, or select properties in the default block to copy to an environment for edit/override, or select an environment from a list of defined environments to add to this config file.

For the yaml editor page:

• there will be two sections: default and environments
• user can add, remove or edit a property in the default section, and the property value can be a string, boolean, number or nested sub-properties. So on the UI, the user should be allowed to select the type of the property value. And for the nested sub-properties, it should allow user to manage them just like the top-level properties above. 
• user can add or remove an environment in the environments section
• in the specific environment, user is able to select a property from a dropdown (collected from the default section) to override the value. 
• For each property or sub-property, user should also able to add a comment. 

And the config file should be stored in the following format (it has a default block followed by 1 or more environment specific override blocks, and the file should be stored as YAML format to allow comments): 

default: # all known properties are defined in the default block. 
  # The most common values are assigned in the default block
  myProp: value 1 
  appVer: 0.1.5
  host: www.mobilex.com" # The url domain for the deployed environment
  dataService: "pd01.mobilex.com/data" # url to access JSON Web API

environments: # specific environments can override the default values 1 property at a time:

  local:
    host: "localhost"
  dev: # environment for developer testing of fully compiled and integrated application
    host: "dev.mobilex.com"
  qat: # qat team validates all compiled artifacts in separate test environment with their own data service.
    host: "qat.mobilex.com"
    dataService: "pd03.mobilex.com/data"
  staging:
    host: "staging.mobilex.com"
  prod: # default is based on prod

Error Handling
For each API, the input data should be properly validated, and proper http status code should be returned in response. 

Security: 
User needs to provide the git repo URL and credentials.

 

Final Submission Guidelines

Submission Deliverable
- Application Design Specification
- Swagger File for REST API
- Mappings from the UI screens to the REST API
- Necessary implementation details for each REST API