EECI2011: Environments and Version Control in ExpressionEngine, by Erik Reagan | Focus Lab, LLC

Home / Our Blog / EECI2011: Environments and Version Control in ExpressionEngine

EECI2011: Environments and Version Control in ExpressionEngine

Oct 25 2011
16comments

Photo courtesy of Marcus Neto

Last week I had the honor of presenting at EECI 2011 in Brooklyn, NY. In the time that I've been using ExpressionEngine I had only met (in person) about ten people from the community. Attending such an event was long overdue and I was thrilled to be there. The content and speaker lineup was fantastic and it only solidified the fact that we use awesome software. My presentation was a lot to soak in, so I'm following up with some additional resources, my slides and most importantly - our EE config setup (as promised).

Version Control / Git Resources

In my presentation I discussed a lot of why you should be using a VCS in your workflow, but I didn't touch on how due to time restraints. Here is a list of resources you may find helpful:

Pragmatic Version Control using Git - Great book on learning Git
Git for Designers
Beanstalk Guides - "Articles, tips and best practices to help you make the most of your design and development workflow." - by the Beanstalk / Wildbit team
16Toads Git resources - Resources collected by Paul Burton while diving into Git
Developing ExpressionEngine sites with MAMP, Git (Tower) and Beanstalk Part 1 & Part 2 - by John Faulds
PeepCode Git learning - Excellent resources for learning Git from PeepCode
A web-focused Git workflow
A successful Git branching model - The "git flow" model I mentioned being good for software / add-ons
Version Control for ExpressionEngine Using Git - by Ryan Masuga (of Masuga Design & Devot:ee)
Using Git to Manage an ExpressionEngine website - Part 1, Part 2, Part 3, - by Stephen Lewis (of Experience Internet)

Environment Config Setup

Another part of my presentation showed some code samples from our EE config setup. We've extracted the core of this setup into a GitHub repository for all to check out. I'll spare the technical details and just say you should check out Focus Lab's Master EE Config repository. If you would like to contribute to the code, there are notes in the repo regarding how.

Take a look and let me know if you have questions (below in the comments).

Slides!

Lastly, you can view the slides below or download them here.

Thanks again for the great feedback after the presentation. Feel free to drop me a line in the comments below or on our contact form if you would like to discuss my topic any further.

Share your thoughts below

Why You Should Learn to Build EE Add-ons by Erik Reagan
The ABC’s of EE Add-on Development: Part 2 by Erik Reagan
Help shape my EECI2011 presentation by Erik Reagan
Utilizing the Template Debugger in ExpressionEngine Add-ons by Erik Reagan
The ABC’s of EE Add-on Development by Erik Reagan

Christopher Imrie on October 25th, 2011 5:38 pm

Awesome slides. Got some great config items in there, and I love the clean separation of the files. Your .gitignore slide may become my new “go to” gitignore reference.

Sorry I missed the presentation, even though I was in NY, I was there on my Honeymoon. I love EE, but not that much ;)

Erik Reagan on October 25th, 2011 6:10 pm

Thanks Chris. Glad you like what you see. Let me know what you think if you dive into the environment/config stuff.

I totally respect the absence too. I missed last year’s EECI because it fell on my anniversary.

Kelly Packer on October 25th, 2011 10:19 pm

I’m sorry I didn’t get a chance to meet you at the conference. I really enjoyed your presentation. Can you give some insight on your team work flow as it relates to the database? For example when you add an add-on that makes changes to the db, does everyone working on the site install it in their local sites? Then everyone syncs their schema via navicat to the dev server? Or how do you handle this? Thanks.

Steven Grant on October 26th, 2011 12:02 am

Finally good to meet you Erik - bummed I didn’t get to hear this as I was looking forward to it.

Hopefully when I get back home I can go throw your config setup a bit more. First glance doesn’t look too different to what I have but I can see what you meant a couple of months back about how it can apply for MSM sites too.

Erik Reagan on October 26th, 2011 5:40 am

@Kelly

Thanks for the kind words. Sorry we weren’t able to meet.

Can you give some insight on your team work flow as it relates to the database? For example when you add an add-on that makes changes to the db, does everyone working on the site install it in their local sites?

Sure! We’re actually still refining this a bit, but typically we install add-ons locally first, then if nothing goes crazy we’ll install a second time in our shared dev environment. For updates we tend to perform those locally first (again, to make sure nothing goes crazy) and then run the update in our shared dev environment.

It almost depends on the add-on though. I investigate most of what an add-on does with the database prior to installation. The reason is so I can prepare notes on how to deploy current and future changes from that add-on.

Does that help?

@Steven

Likewise! I look forward to hanging out again in the future.

...I can see what you meant a couple of months back about how it can apply for MSM sites too

Absolutely. Now that you mention it, I might consider throwing in an MSM example to the repository. It would probably help kickstart some people who need that.

Patrick Brumfield on October 26th, 2011 11:39 am

Thanks for spelling this out so clearly, Erik. I was bummed not to be able to go to EECI, but the community at large is benefitted by your presentation and content above.

Cheers!

Kelly Packer on October 26th, 2011 1:23 pm

Yes thank you that is helpful. So for example when you use something like Zenbu, which can be time-intensive to configure if there are a lot of channels, you would install it locally, configure it locally and then install it on dev and configure on dev? Or do you use navicat to sync schema and data to dev? Do you find there is overlap in each person’s local setup, each having to do a lot of configurations to their local site?

Erik Reagan on October 26th, 2011 1:31 pm

@Patrick

Thanks! Hopefully you can make it to the next EECI.

@Kelly

So for example when you use something like Zenbu, which can be time-intensive to configure if there are a lot of channels, you would install it locally, configure it locally and then install it on dev and configure on dev? Or do you use navicat to sync schema and data to dev?

If it’s a time intensive process such as Zenbu (or customizing a large Publish Layout), I just do it once and then use Navicat to transfer schema or data.

Do you find there is overlap in each person’s local setup, each having to do a lot of configurations to their local site?

We have a pretty small team. Typically, I’m the only one doing the custom add-on development or initial add-on configuration. That will change eventually, but that’s what it looks like now. Because of this fact, I’m typically the only one doing any development on a local database. Most of the team develops with the remote (shared) database in use. That means there isn’t much overlap or re-configuring to be done.

Simon Britchford on October 27th, 2011 12:23 pm

Hi Erik,

Enjoyed your talk at EECI last week. I realize that it was an overview and here’s a few questions I have as a newbie with version control:

What EE files are controlled with Git?
Where do Git files reside, physically?

Erik Reagan on October 27th, 2011 12:29 pm

Thanks Simon.

What EE files are controlled with Git?

We track all files in a project except the following:

- Local developer’s config file (specific to our multi-environment setup)
- Custom uploads through EE
- The EE cache directory

Sometimes there are more ignored files depending on the project. See slides #33 and #34 on the presentation (note that these numbers are slide numbers specific to SpeakerDeck, and not the numbers in the bottom left of the slides themselves).

You can read more about ignoring files here

Where do Git files reside, physically?

The files sit right where you have them on your harddrive. There is a hidden .git directory at the root of your repository which stores “blobs” of data about the repository. It’s the history of your files, directories, meta data etc.

Alain Foidart on October 28th, 2011 9:35 am

Thanks so much for sharing this Erik.

Quick question, I’ve setup a site using your ee-master-config setup and I get blank pages on both the front-end and back-end now. I turned debug to 1 and get the following error: “Notice: Use of undefined constant ENV - assumed ‘ENV’ in ... ” and a few more notices and erros all relating to “use of undefined ENV”

So I looked through your comments in the config.master.php file and you say “Some config settings are used in multiple (but not all) environments. You will see the use of conditionals around the ENV constant in this file. This constant is defined in ./config/config.env.php which is required in the front-end index.php and the CP admin.php files. This means the constant is available at all times in the APP page loads.”

I’m sure this is the part I’m missing - I didn’t see info about this in the readme file - I’m a bit new at this so I very well could have missed something.

How would I go about “requiring” this file in my index.php and admin.php pages?

Thanks again for the great work!
Cheers!

Erik Reagan on October 29th, 2011 12:12 pm

@Alain

Thanks for trying it out. You actually caught a small bug from my transition from our private code to making it publicly available. I missed a conditional.

I’ve updated the code on GitHub with the fix. The important change can be seen here.

Let me know if you have questions about that.

Thanks!

Judd on November 14th, 2011 1:47 pm

Hi Erik!

It was nice to meet you at EECI (we grabbed Tex Mex).

Thanks for sharing your setup, it’s really cool to see how other approach this.

Couple questions:
- how do you handle deployment/rollbacks?
- once a site is live, how do you handle the production DB? (e.g., users add content but you’re working on a feature locally that changes the schema.)

Thanks!

Erik Reagan on November 15th, 2011 9:34 am

Thanks Judd

It was nice meeting (and dining with) you too.

how do you handle deployment/rollbacks?

We’ve never had to actually roll back code. We’ve tested it a few times to make sure it “works” so the idea for us is to re-deploy the full state of a specific commit from beanstalk (can be time consuming). The DB would be restored to its most recent dump as well.

Again, we haven’t had to do this and it would be trial by fire if it happened.

once a site is live, how do you handle the production DB? (e.g., users add content but you’re working on a feature locally that changes the schema.)

Our basic rule of thumb is that schema or structure starts locally and flows up stream. Then content flows downstream (typically in the form of a full DB dump after a new feature deployment). It really depends on the project though. We play this one by ear since there is no simple solution.

The simplicity of the above rules quickly breaks if you work on multiple new features that change schema locally but deploy them to production separately.

So the real answer is that we don’t handle every site the same way.

Damien Majer on November 23rd, 2011 3:16 pm

Hi Erik, can you explain a little more about what you mean by content flowing downstream whilst developing a new feature locally in your reply above. I use tower and beanstalk and am now looking to use navicat to work alongside this workflow but am uncertain about how to sync DBs when working locally on a new feature whilst in the meantime new data is being added all the time to the production DB.

Jarrod Payne on April 27th, 2012 4:08 pm

@Damien Majer

I too use Git Tower and Beanstalk as well. I also frequently develop new features, often ones that change DB schema. Will navicat help? If yes, how so? I am not SQL guy.