Development/Deployment on Amazon EC2

I have been looking into bedrock and possible sage, but at the very least bedrock, for some time. I run a development team of 8, and our current setup is as follows:

development is completed on an ec2 server (dev server) as a subdomain
site is moved to another ec2 to go "live"
changes are made on live server
all done via stp

I built our core theme and plugins, but would like to use bedrock and add the things we use to it.

here is where I am stuck, as I have not used version control in some time, and the server administrator is not sure how to set all this up either.

what would be the best setup? build locally, push to staging server, then to live server? what do I need to know about git to make this happen? I have been looking at gulp and bower and composer, but its alot to take in, much different than our current workflow. I want to make my teams workflow better, quicker, more up to date. the way we build is outdated and archaic. we build and host hundreds of sites for clients.

I would really appreciate any guidance or help, pointing me in the right direction. thanks for your time!

I’d say you’re going about this correctly.

Start with learning and use source control properly because that’s the single most important thing you can do. In my opinion software development begins with source control.

It’s also way too big a topic to really get into here. There are much better resources. But really simply:

  1. Everyone develops locally
  2. All work is committed to a Git repository
  3. Git repository to used to “deploy” changes to various servers (this just means pulling in changes on remote servers where you’ve cloned the repo)

Check out and the “official” free Git book:

I would also highly recommend starting with Bitbucket or GitHub to manage your private repositories.

It’s also worth mentioning that you should not bother trying to run WordPress on an EC2 micro instance. It will only cause you pain.

@dhaynes1206 Consider having one of the main roots devs visit your team for a few days. With your client volume and a full team to coordinate, it may be particularly important to not lose time (and maybe team members) to trial and error while developing your workflow.

If the tools are unfamiliar, there’s a learning curve, but they’re pretty ideal for a team and business like you’ve described. They’d put you way ahead of the majority those working with WP.

thanks for all of the help and insight, I am fully immersing myself in everything git right now. I appreciate the insight and pointers, any and all is appreciated!

how would I go about having the team visit?

Check out

There’s no explicit option for that so you could email if you wanted to arrange for something like this.

so I successfully did the following:

  1. cloned bedrock down to a local project folder (using WAMP)
  2. created a bare repo on a staging server
  3. added remote to local repo for staging
  4. initial commit and push
  5. added post-receive hook, so when pushed to staging, it updates live directory

everything worked, changes were moved etc. the question I have is this - if I have a base bedrock package like this and the gitignore file says not to put the core (/wp), how would you go about getting those files there? My thinking is this - a developer clones bedrock down and builds the theme/functionality locally. they then push to staging, which should update remote. is there already a production site configured with bedrock and git just updates the /app folders?

thanks for any help!

Run composer install on the server as a part of the deployment process

ahhh i see it installs those packages via composer, so I can push to staging, run composer with that json file and it adds those files. awesome!

ok so stay with me here (I want to run this by all you wizards :smile:)…

  1. dev clones bedrock (we will have our own package in our hosted repo, updated compass file etc)
  2. dev creates local db to run the install and get wp site up and running
  3. dev creates site theme and functionality, plugins etc
  4. staging repo is created as a bare git repo, local files are pushed into here
  5. hook created so once files are pushed into staging remote, they are pushed to production

does this sound about right?