New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
amandavisconti opened this Issue Aug 3, 2013 · 5 comments

Comments

Projects
None yet
4 participants
@amandavisconti
Contributor

amandavisconti commented Aug 3, 2013

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

@ghost ghost assigned patrickmj Aug 3, 2013

@rlskoeser

This comment has been minimized.

Show comment
Hide comment
@rlskoeser

rlskoeser Aug 3, 2013

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

rlskoeser commented Aug 3, 2013

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

This comment has been minimized.

Show comment
Hide comment
@mialondon

mialondon Aug 3, 2013

Contributor

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.

Contributor

mialondon commented Aug 3, 2013

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

This comment has been minimized.

Show comment
Hide comment
@mialondon

mialondon Aug 3, 2013

Contributor

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.

Contributor

mialondon commented Aug 3, 2013

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

This comment has been minimized.

Show comment
Hide comment
@rlskoeser

rlskoeser Aug 4, 2013

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.

rlskoeser commented Aug 4, 2013

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

This comment has been minimized.

Show comment
Hide comment
@amandavisconti

amandavisconti Aug 8, 2013

Contributor

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

Contributor

amandavisconti commented Aug 8, 2013

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

@ghost ghost assigned rlskoeser Oct 8, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment