4

Short story:
What are some of workflows regarding the database teams are using to develop locally and then push to a central dev site. When each dev is creating their own templates and variables (not to mention content), how is that database being merged with others without erasing the work one or the other has done? I've seen at least one attempt at a mysql-query recorder, that I could then use to insert into the parent database instead of trying to merge it. I've used those for WordPress and know those aren't always 100%. Are there any other workflows?

Long story:
I'm new to developing with a team. The team I'm working with is new to best practices and really working together. In the past it's been pretty much every for themselves, a lot of cowboy coding through FTP on live sites, and more. However they brought me on because we are now getting larger projects. Great.

First I introduce them to git. Everything is great. They understand the benefits, they get use to develop locally, push to staging, then push to master. We use dploy.io to actually make the deployments from our git branches. Again, great.

Now we have a few sites that several devs are working on. Git merges, pull requests, conflicts, no problem. However seeing that ExpressionEngine's core is the database, we start to see issues. Dev A has a copy of the database and so does Dev B. Both are making content changes as well as creating new templates and variables. Both databases can't make it to the staging deployment. We tried some database merging (I come from a back-end world and have no problem getting dirty with databases), however that can be so time intensive.

So we have a (almost) great current solution, using an online IDE. Through Cloud9 (c9.io) we are connecting via ssh to a VPS we have set up for Dev work. This way we are collaboratively working on the same files at the same time, as well as sharing the same database. There are no more git conflicts with each other, no more separate branches for each dev, no more database conflicts, etc. Life is grand. Until Cloud9 goes out for an hour one day. Then we see the error of our ways. What would we do if there was a serious deadline to meet tomorrow and we are left twiddling our thumbs because we can't connect? We could go back to an FTP workflow, but would seriously slow things down.

So this leads to my question: What are some of workflows regarding the database teams are using to develop locally and then push to a central dev site. When each dev is creating their own templates and variables (not to mention content), how is that database being merged with others without erasing the work one or the other has done? I've seen at least one attempt at a mysql-query recorder, that I could then use to insert into the parent database instead of trying to merge it. I've used those for WordPress and know those aren't always 100%. Are there any other workflows?

Improve this question
  • For a related question also see Migrating between Development, Staging and Production for a pre-existing ExpressionEngine site – Alex Kendrick♦ Feb 15 '15 at 21:09
  • thanks. Yes. I've read all the articles on here over and over, and plan to keep reading them to get as much out of them as I can. We've done well with content freezes, and migrating the databases between servers, it's really come down to when we are doing the initial development which involves a lot of DB changes at the same time by multiple people. Plus some of those articles are a little dated and looking to see if any one has come up with a "this is the way to do it". – Andy McCormick Feb 16 '15 at 1:59
  • Closing this as a dupe, since the question remains the same, and new answers can be added there. – Derek Hogue♦ Feb 19 '15 at 23:51
1

What we in my current team are trying to do is to have as much data in files as possible. That included not just the system add-ons, but templates, snippets and ExpressioEngine config.

We then keep all of those data synchronized with Git.

There are some things which are still stored in database of course and cannot be pulled to files - the data stucture, channel entries, settings for some add-ons etc. Those are saved in 'master' database that we all are connecting too. Everyone is free to set up a local copy for that of course.

We also make database backups on periodical basis and those backups are stored in Git. So we should be able to get a recent copy of data even if the main server is down.

I'm also eager to hear what other approaches people are using. Thank you for bringing this up!

Improve this answer
  • Thanks for the response! A couple follow ups: - Maybe it's my ignorance when it comes to EE, but I am correct that Templates, snippets, variables must be created in the database first, before being saved as files, correct? That's the first big issue that we ran in to, is if the database hasn't defined a template, and we push it the staging site, it will delete it. - How does your set up look like with the Master DB? wouldn't everyone have different file paths on their local machines and are they doing anything locally before pushing to the central site? – Andy McCormick Feb 15 '15 at 17:53
  • We use FocusLab master config, that is of great help when you work with multiple environments. And yes, the templates/snippets need to be created and saved in database first. – Yuri Salimovskiy Feb 15 '15 at 18:10
  • 1
    +1 The FL Master Config is really useful for this. And you actually can create templates just by adding the file and without first creating them in the database. See Creating Templates Via Flat Files. But at some point you'd want to use Synchronize Templates to get the database fully up to date. – Alex Kendrick♦ Feb 15 '15 at 21:06
  • And for Snippets there is Snippet Sync – Alex Kendrick♦ Feb 15 '15 at 21:16
  • @AlexKendrick . Thanks for that link! I'm still getting situated in EE. I have had the best luck with synchronizing the templates. Sounds like I need to do some more reading. – Andy McCormick Feb 16 '15 at 2:29

Not the answer you're looking for? Browse other questions tagged or ask your own question.