12 11 / 2011
ExpressionEngine + Version Control
Version control has long been an integral part of any development team. One of the challenges I face when marrying the ExpressionEngine templates and version control with separate development, staging and production environments is keeping everything in sync. Let me begin by explaining a little about the development environment we use:
- Developers begin coding on their local machine using MAMP, committing frequently. The database lives on the staging server so that when the push to staging happens, no database merging/updating will be needed.
- Once the developer has a stable version of the site, he/she pushes their commits to the “develop” branch in a remote Git repository.
- The Git repository fires off a post-commit hook to a service that automatically deploys the code to the staging server where others can QC the work.
- After all the stakeholders are satisfied with the code as it lives in staging, the developer merges the code into the “production” branch and pushes to the repository.
- The Git repository fires off another post-commit hook that tells our deployment service to push the code to the production server.
- If needed, the developer will make any necessary database changes on the production server at this time.
- Finally, the developer and stakeholders QC the code in production to make sure all is well. If there are issues, our deployment service allows for a quick and easy rollback.
ExpressionEngine, in it’s current form, makes this workflow difficult to enforce. This is because anyone with the proper permissions can navigate to the template manager and make changes to a template that is in production—thereby bypassing source control and the entire workflow. Obviously, this is a huge problem because our production severs don’t commit changes back to the repository for obvious reasons. So when someone edits a template on the production server, nobody knows it happened and when we deploy a change to that template, it is very likely that the change will be lost or our working copy will become out of sync (depending on how we deploy the project).
You may be asking why go through all the trouble of setting up three separate environments and keeping your templates in source control? I’m not going to state the case for source control here but it really comes down to three things:
- When bad code is pushed to production, we need to know who wrote it and be able to quickly revert back to a previous version. EE’s template manager doesn’t give you the line-by-line blame that source control does. Also, the template editor promotes “change a line and save” type development that quickly makes it’s version history obsolete.
- You owe it to your clients to be diligent about the quality of work you push to production. Having separate environments prevents the developer from making non-tested changes to the code that break other parts of the production site.
- Source control is great for multiple-developer teams. There is nothing worse than two developers accidentally making changes to the same template, thus overwriting each other’s work. This is preventable and simply won’t happen with source control.
In an effort to preserve our workflow, I created an extension that disables the template editor in ExpressionEngine letting the developer know that the templates are under source control. This extension makes the templates and template groups in EE read-only. It doesn’t affect things like synchronization, PHP input/output parsing, and access control.
How to Use
This addon is just an extension that modifies some of the control panel’s code. There is no code to insert nor are there any settings. Just install and go.
Download
You can get the latest version of this extension from Github
