Goal is to run a setup similar to Media Temples GridServer using NginX Server Blocks optimized with varnish for lightning Wordpress installs, all under app1.domain.com structure, while also housing gitlab under gitlab.domain.com.
This is branching off my other question: https://www.digitalocean.com/community/questions/staging-production-environments
Ideal end goal is to:
I know this cover a lot, trying to figure out the best method for staging/prod deployments while keeping a revision history (git repo) and making sure everyone has an exact copy of environments/dbs/dependancies (vagrant/composer).
Any help would be much appreciated!
-CK
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
ckiriaze do you have new informations about this?
Will you make tutorial after you done with this? My idea was very close to that. So: <br>- domain.com for main site <br>- gitlab on gitlab.domain.com <br>- development part dev.domain.com/projcet <br> <br>But somthing what i want to make to move gitlab main repo folder from there original location to dev.domain.com location. In that case i don’t need any hook. Master branch will be always in sync with dev. Can someone help with this?
Thanks for the reply Andrew! <br> <br>Had a look at those links, and Im familiar with the auto deploy script/post hook having used that with bitbucket, but didn’t like the fact that I couldn’t deploy based on branch rather than always, so thanks for that bash script, thats pretty nifty! <br> <br>Came across, bedrock ( https://github.com/roots/bedrock ) which is interesting but doesn’t yet support Vagrant or a method of syncing dbs, but the closest Ive come across that implements pagoda/heroku is the dokku app. <br> <br>1. What are your thoughts on easyengine ( https://github.com/rtCamp/easyengine ) or puphpet ( https://puphpet.com ) ? <br> <br>2. Back to implementing gitlab as a nginx server block @ gitlab.domain.com, is that ideal/practical compared to having the gitlab.domain.com under its own droplet? <br> <br>3. I love the idea of setting up a boilerplate so to speak, and creating a snapshot from it to easily create new projects! If using vagrant, however, you mentioned there might not be a need for it. If not using vagrant, would the best method for keeping teams in sync be to launch the droplet from the image, setup the wordpress install on the remote first, then pull it everything down w/ a sql dump?
It sounds like you’re up to some cool stuff! I’m excited to hear what deployment ideas people come up with. <br> <br>The first thing that jumps to my mind is regarding 4b. I’d personally set set up automatic deployment after each git push to the gitlab instance. You can setup a post-receive hook that deploys to the different environments based on the branch. That way when you’re ready to deploy to production, you can just merge master into a production branch. Something like: <br> <br><pre> <br>#!/bin/bash <br>while read oldrev newrev refname <br>do <br> branch=$(git rev-parse --symbolic --abbrev-ref $refname) <br> if [ “master” == “$branch” ]; then <br> # Deploy to staging <br> fi <br> if [ “production” == “$branch” ]; then <br> # Deploy to production <br> fi <br>done <br></pre> <br> <br>See: http://stackoverflow.com/a/13057643/598929 <br> <br>As far as Wordpress specific things like whether to check in the whole site, there are lots of opinions out there. Some interesting things I’ve come across: <br> <br>http://roybarber.com/version-controlling-wordpress/ <br>http://www.efeqdev.com/website-development/this-is-how-we-version-control-and-deploy-our-wordpress-websites-with-git/ <br>