Specifications

command line deployment

• create_stack, im a fan of specifying ONLY one param here, a param that we were missing until now - the project id. Be it mx/uk/ucb etc. DE/AU are using UCB. MX is not. Neither UK.
• so the create_stack command should know all the versions at runtime by itself. for this it will have following keys (ucb as example):

ucb:last_stack_version

ucb:package:ucb_lib:version

ucb:available_packages

• create stack will grab a new incremented ucb:last_stack_version for the specified project, then iterate over each package from ucb:available_packages and fetch its last version from ucb:package:foo_lib:version.
• at this point we have a new stack with all current versions, ready for changes, next we call... add_package_to_stack - unless specified the version of stack, this task should append built version to the last stack.
• we can add packages multiple times. We can call new create_stack when we need to jump to next stack version. For exampls:

QA wants us to update backend and frontend in one go. 1xstack_create, 2xappend.

QA signifies problems with compatibility: stack_create, append, stack_create, append. Here we have a stack version to rollback to halfway.

• lastly, the web.py part of gachette needs to implement "API" calls for updater.py script. It needs to answer via uwsgi what was untill now answered with nginx statics files.
• here is another problem. we should think about rewriting this script a bit. It worked with nginx static files, so it used call in not-so-efficient manner. Mainly, we have a /packages and /stacks directory trees served by nginx. One is telling about version another one about filenames... which can be fixed slightly by... Changes to updater.py:
• let gachette uwsgi take over the responses about packages - updater.py can parse json received from gachette, so in one call we can return ["version": "hashtagdfghj", "filename": "something.deb"]
• finally, fix the uwsgi webcallback in gachette so it uses the same code as fab task add_package_to_stack. At this point we have the comandline building complete.

Web GUI via garnison.

I think it makes sense to have a 3 screen workflow:

1. Default dashboard with grid showing stacks for different markets. Button create stack, does exactly what the described above stack_create does

2. New stack screen. On this screen, we have the new stack, with curent versions of all packages, and with checkboxes (next to package names) that allows the QA member to "bump up" (rebuild) checked projects. Clicking submit, will trigger the builds of each selected project and appends them to stack.

3. We are back to dashboard, fresh stack can be deployed only to staging, after staging it can be marked "Stable" (golden), when stable it can be deployed live.

*dashboards aka garnison, does API calls to gachette for fetching data, triggering builds, and writing monitroing data (whos building, whos deploying, when)