search

earthlab / dev-earthlab-site

Development of active learning focused data intensive university classroom materials.
MIT License
0 stars 3 forks source link

Better deployment through multiple remotes? #36

Closed mbjoseph closed 7 years ago

mbjoseph commented 7 years ago

Our current setup for deployment seems clunky due to the copy-pasting, extra steps involved with adding and committing twice, and the resulting set of git histories which do not really match.

Do you think it's worth instead using two remotes named "dev" and "deploy" which point to the earthlab/dev-earthlab-site and earthlab/earthlab.github.io repositories instead?

e.g.,

So that we always develop and push to the "dev" remote, and then when we're ready to deploy, push to the "deploy" remote?

This would require that we delete the current earthlab/earthlab.github.io repository (with a small amount of downtime for the site, and then recreate it, add it as a second remote (named "deploy"), and then push to deploy.

Does that sound like a good solution?

lwasser commented 7 years ago

hey @mbjoseph i'll look into it! i don't fully understand how this works in the instance that you want to push just a set of specific files to the live site. if you're commits aren't organized properly, it will be hard to sync properly while you are working on particular sets of files. I may not understand fully how this works.

mbjoseph commented 7 years ago

Ah that's a good point. If we want to only push a set of specific files, how about using branches and pull requests?

lwasser commented 7 years ago

I thought about branches. But again I see the same issue unless you can do a specific pull request on a set of files? Would I have a different branch then for each set of lessons I build? That is the only way I know to do that particular thing

I’m open to this workflow potentially. The challenge will be – it will be confusing for others who want to add content to the site. And we will need to establish rules about what dev items goes on a branch.

lwasser commented 7 years ago

idea -- may or may not make sense. what is we use BRANCHES for new functionality BUT use the other repo for material development. That way, content development issues can happen in the dev repo and functionality in the live site? Just a thought. is that more complicated? The history of the lesson is then in the dev repo. the history of the site development stays in the main live repo.

mbjoseph commented 7 years ago

That sounds better than our current workflow, but still complicated (e.g., how to easily sync changes between the two repos?). I'm not totally sold on any approach yet - but it seems like the "best" approach would:

I'm going to think about this some more. Maybe we can talk IRL at some point and a solution will precipitate.

lwasser commented 7 years ago

Sounds good. Yea I’m not sold on any of the options yet either. All sound complicated.

All I know is I need to be able to test lessons with functionality as I build content so having a dev space is important for me. We can chat more.

lwasser commented 7 years ago

This issue was moved to earthlab/earthlab.github.io#26