Discuss process/schedule/responsibility for moving updated GitHub files to live site

[amandavisconti]

Is someone at CHNM willing to automate this, maybe? cc @rlskoeser

[rlskoeser]

good questions.

in the short term-- I pushed fixes since launch to the heroku dev site -- if people want to test I can probable update the main site in the morning.

longer term, I'd like to get the git repo set up with git flow so we can separate development, tag releases, etc. we'll also need to automate the deploy so it's easier to push out

[mialondon]

It'd be good to discuss the QA/quality gate for pushing from dev to live - how do we maintain the vision for the tool while expanding the functionality, adding micro-content, let alone adding new APIs etc?

In the immediate future, if we can push the latest commits to dev over brunch, do a quick review and then push to live it gives everyone a chance to deal with any immediately niggling issues.

[mialondon]

Just a quick note re the discussion of 'lazy consensus' as the process for approving changes to live - see http://nowviskie.org/2012/lazy-consensus/ for more - basically if someone's pushed changes to dev, they let everyone know and if no-one objects within 48 hours (?) then it's fine to go live. That way people who really care can respond but you don't have to if you're not bothered.

Also we should write a simple test script for basic regression testing (especially for outside people adding code); document the initial API choices (i.e. broadest possible coverage for the smallest number of coding hours, especially with the similarity of the DPLA and Europeana APIs) as guidance for potential contributors and come up with some kind of vision statement and tone guidelines to inform UX and functional changes.

[rlskoeser]

We now have a heroku site that should auto-update when people commit to master (assuming tests are passing). Should make it easier for people like @fontnerd to commit font/css/etc changes and see the results without having to run their own development instance.

However, there may be some differences running on heroku vs. running on apache/mod_wsgi - not sure if it could cause problems in production we wouldn't/couldn't catch in dev.

Also, we need to automate/script the production deploy and make it easy to rollback if necessary.

[amandavisconti]

Thanks for making the heroku site auto-update, @rlskoeser. Should be very helpful with styling/results card work!