When starting a project, or joining a project that hasn't done this yet, the first thing you should do is set up proper gitignore files. There should be a master gitignore in the project root based on the h5bp master gitignore, and a cache dir specific gitignore in each cache directory. Without proper gitignoring, junk files tend to find their way into commits and removing them becomes a pain, as everyone gets modified/removed conflicts forever after. The reasoning behind using a gitignore file for each cache folder separately instead of including path/to/cache_dir/* in the master gitignore is that git is inconsistent in whether the folder itself is actually stored in the remote git repo. It is most consistent to have gitignores ignoring all but themselves in each cache directory. Then that directory must always be in the remote repo in order to contain the .gitignore file.
For expressionengine installs the cache gitignore would go in:
- /system/expressionengine/cache/
- /public_html/images/sized/ (imagesizer cache)
- /public_html/images/made/ (ce_image cache)
- /public_html/images/remote/ (ce_image cache)
Also add the following to the master gitignore:
# ExpressionEngine image caches
_thumbs
Recovering from this mistake takes only a few magic commands. Running the following in your project root should purge all of the useless files that may have been commited to your repo, without removing your local filesystem copy. It will use all .gitignore files in your repo, including the master and cache-dir gitignores described above.
git ls-files -i --exclude-per-directory=.gitignore -z | xargs -0 git rm --cached
git commit -m "Removed junk files."
If you want to remove all gitignored files from the repo and delete them from your filesystem, you can do:
# Look what will be removed
git clean -ndX
# Go ahead and remove for real
git clean -fdX
git commit -m "Removed junk files."
To begin, we should start all of our projects with the htaccess from h5bp to leverage all of the goodies. Besides this, whenever we need to have http auth applied to only one server, instead of creating a separate htaccess for it, we should use the conditional auth snippet which applies http auth only in a certain environments. Finally, for SEO deduplication, one should either force or suppress a trailing slash at the end of urls.
Note that older hosts cannot handle the CORS section of the h5bp htaccess. This usually manifests as a 500 error. Simply comment that section out.
For ExpressionEngine projects, use the ExpressionEngine Permissions Script. This will simplify getting the permissions correct for EE to function, and should be safe to run in any environment, including production and staging.
When making a new repo, run git flow init -d instead of git init, this will get your repo all set up with a develop and master branch and plop you onto develop. Also run this when pulling down an existing repo. To summarize the workflow, all development should occur on 'develop', and when ready to push to a live server, git flow release should be used to make a release which will then go into master. The goal is for every commit on master to be a shippable release. For more about the git flow branch model, refer to the original article adn this very succinct introduction to the commands.
Submodules are a pain to maintain. There are many pain points that we have discovered over time. Best to simply avoid them.
Adam Chambers has spearheaded an effort to make using require.js easy for our CMS-driven work, and allows us to scale from simple modules to full backbone without major rearchitecting. Consider however that we should strain to achieve the fewest js files possible, which for little js functionality would mean not using body class-based loading of modules. For super large js projects, angular.js has it's own loading mechanisms.
Tracking all of the individual environment configurations allows us to use deployments in beanstalk without worrying about changing configuration files after each push. Tracking developer configuration is perhaps not necessary, but is convenient as a backup.
For codeignitier, this is as simple as adding a subdirectory to your application/config directory named after your environment, with a copy of database.php inside it. For ExpressionEngine, use ee-master-config. For Zend, the conditional auth snippet provides an easy way to set the env variable on a per environment basis.
Laxative is a bash script I wrote to allow for better and easier tracking of MySQL (and with Adam's help, MongoDB) database dumps. Typically this script will reside in a .db directory in your project root, where it will also save the dump files. Laxative provides the following benefits:
- Every row of a table is on it's own line, minimizing and making changesets more readable in git.
- Various optimizations are applied in addition to keep filesize and dumping/loading time down.
- Configuration from ee-master-config, codeigniter environment directories, or lax-specific configuration files are used to make the commands as simple as possible (i.e. lax load stage).
- Stores schema and routines in separate files to facilitate pulling only schema or routines from another developer's instance into one's own without blowing away all your data.