search

hackoregon / backend-examplar-2018

an example dockerized geo-aware django backend
MIT License
4 stars 5 forks source link

What's the opinion on running the "migrate" command during every Travis build (or any Travis build)? #66

Closed MikeTheCanuck closed 6 years ago

MikeTheCanuck commented 6 years ago

We currently see python -Wall manage.py migrate in a proposed PR #60.

This can be very handy for developers who are making Django model updates on the fly and want to get that propagated to the data layer. It can often be run by developers who have schema-level privileges to the database.

What worries me about enabling this in Travis build scripts by default is that it may catch Django developers unawares - they may be making migrate scripts and committing them to their GitHub repo, but only on the assumption that they're in control of when and how to commit their migrate scripts to the data layer.

If we leave this command enabled in the Travis-enabled CI/CD pathway, we'll surprise any developers who aren't expecting these changes to happen as soon as they make a commit to any branch of their repo.

A few opinions have been raised here - I'd like to see if we have any strong opinions in favour of enabling this command by default: https://github.com/hackoregon/backend-examplar-2018/pull/60#pullrequestreview-117825252

znmeb commented 6 years ago

If it causes problems in deployment / production we should remove it, or have the script that runs it only run it when it's in development.

MikeTheCanuck commented 6 years ago

Well this was a false alarm - not that it was easy to tell from within PR #60, but as of commit 249a191a638409da3c5014fc1277f3b83a22a308 this has already been commented out.

bhgrant8 commented 6 years ago

closing