phil to send me details on deployment structure

[mikelmaron]

• meta tags for facebook and twitter
• responsive design
• front page map and filter
• schools detailed
• comments through disqus or facebook
• set up deployment

[mikelmaron]

Hey Mikel, here are the steps I need you to take to set up the repositories, and roughly how the flow will work:

Setup

1. Create a repository under the Map Kibera gitub organization.
2. Add me (uniphil) as a contributor. It might be good to add dgadmin as well.

I will handle pushing the app to that repository.

1. What is the plan for the production domain?

Flow

Here is what I had proposed to Catalin, and what I have been working toward. The notes are a bit long, and it might seem complex, but it should be fairly simple in practice.

For data and content updates, ie. those by GroundTruth:

• These updates may be tested locally, and then pushed straight to production.
• There will be a script in the master branch of the repo to build the site for production gh-pages, so updates will require just a few commands (to be documented in the readme).
• Source files for generating the site should be pushed to the master branch whenever they are changed. Side-note: this can happen without pushing to production gh-pages, in case you wish to update the content without making it live. Collaborators will be able to preview these changes by pulling from master and building it locally.

For application updates and new features, ie. those by DG:

• Pushing to staging will require: a) merging in the latest content from production, b) building the site for staging, c) pushing it to the gh-pages branch in the devgateway repo. There are a few helper scripts to automate most of this.
• Promoting the staging site to production will require a re-build, since some files must be different (at least CNAME and robots.txt, and potentially all internal links if production is hosted in a subfolder instead of at the root of a domain).
• The staging vs. production repos will be coordinated by setting up a local repository with two remotes. This is only a concern for development of the app that requires the staging server, and will be documented in the readme.

For changes that require coordinated updates between data and the application:

• We can start by handling them case-by-case. If this happens frequently, I have ideas for processes we could use for this, but otherwise we can just email/call and do it ad-hoc.

Well that took more words than I expected. Let me know if anything is not clear.