Thoughts about how best collaborate on the project

[alpacaaa]

I'm opening this issue to discuss and come up with a development workflow that will make developers life easier and pushing changes to production as bulletproof as possible.

This is not meant to be specific to xpathr but hopefully be useful for future projects too.

The first thing I'd like to discuss is how to integrate changes into production. We currently have an ensemble branch which should track the stable version of the app. Given that, the production environment should always be synced with ensemble. The ensemble branch tracks different submodules. If a change is made to the repo the submodule is pointing to, the reference must be updated. The problem is that if I make a change, I should update the submodule to point to my repo. But then someone else integrates is work, so the submodule is updated again to track his repo. I fear this will soon lead to headaches.

The only solution I could find is to use one central repository as the source. Every change must be first integrated with the central repository and then submodules are updated accordingly. This is not very flexible, maybe there are better approaches.

And then there's the database. We are currently using dump_db and which is nice and simple. Should we stick with it?

[bauhouse]

I think it would be best to have a single central repository. So, if you add me as a collaborator to the alpacaa/xpathr repo, we should be good. Or as an alternative, we could maintain that as the development repo, and have a private repo for production on the server itself. (See @phoques's article on using Git with SSH.)

I do like the simplicity of the Dump DB extension. It does force us to use a workflow where database changes must come from the production environment. Generally, I will test structural database changes locally. Then, when I am satisfied that everything is working as required, I will make the same changes to sections and fields on the production site. Everything else can be deployed with Git: pages, events, data-sources and utilities. SQL changes can be saved to a private sql directory with Dump DB and maintained as a private Git repository.

It's not really ideal for a large dev team where lot's of structural DB changes need to be made, but it's been working well for me for small projects or projects where I have a lot of control.

If you have any other suggestions, I'm open.

[alpacaaa]

I like that.

So the process for deploying a new version would be:

• dump the production database
• import it locally
• make structural changes
• test that everything works
• commit everything
• make the same structural changes in production
• pull new commit

Sounds good!

I added you as a collaborator, let's keep alpacaaa/xpathr as the "official" repo. Going to align everything now.

Aah!! I'm flooding the repo with dumb commits trying to get the workspace submodule correct, I live that to you before exploding :D

[bauhouse]

Awesome! Thanks for fixing up the submodules.

We should also pull in the ui submodule as well. It is still pointing to my fork. We should probably just remove the Git repo for the UI and add the files into the integration branch. I suppose this should really become the workspace branch.