Getting Your Code on the Server
Now that we know all the tools we should have in place, the next step is using them to create a WordPress site, version control it, and ultimately get it onto a server. There are numerous other articles explaining various methods to do this, so keep in mind that you may want to do things a little differently and that is okay. You are probably going to make mistakes along the way, I know that I did, it only serves to make you a better programmer.
1. Create a new site in AMPPS
The first step is going to be creating the site in AMPPS. To do this, log into the control panel by clicking on the application followed by the house icon. Under configure there is an option to add a new domain.
This will create a folder in AMPPS www directory, which is where your site will be. I typically terminal to that directory and remove the cgi-bin folder because Git doesn’t like non-empty folders but you can also remove it using SourceTree or Tower.
2. Setup Git in Beanstalk/Locally
Now that we have a working web directory on our server, we need to have a git rep set up before we install WordPress so that we can track all the changes. Log into Beanstalk and create a new repo, don’t worry about the deployments for now, only focus on naming it something cool.
When you are done setting up your Beanstalk repo, it will provide you with the details on how to set up your new local repo. There will be a path such as: https://lukesaccount.git.beanstalkapp.com/site.git.
You have several options to clone this repository, using the command line to clone the repo or using a program like SourceTree. We will use the later since it is more visual and probably less error prone to start off with.
Open up SourceTree and click on the New Repository Button, then choose clone from URL.
Using the path of your repository that Beanstalk provides you, copy the URL into Source URL field. Once that is done you can use the button beside the Destination Path to locate the directory of your website you want to use git with. This by default is /Applications/AMPPS/www/site-folder when you are using AMPPS but will vary on whatever local server setup you have. Before you set the destination path, you can use that window to delete the cgi-bin folder as I mentioned you could do before. You cannot initialize git in a non-empty directory.
Once you complete cloning the repository, any changes you make will be recorded, however you will still need to remember to do standard git commands or use SourceTree to stage, commit, and then push the files.
With SourceTree this will be the workflow:
- Change a file
- SourceTree sees you made a change
- Check the files you wish to stage in the commit
- Using the commit message field, type a message for your commit and press Commit
- At the top press the Push button (alternatively there is an auto-push button below the commit message field)
With Terminal here is your workflow:
- Change a file
- In terminal type git add .
- Next type git commit -m ‘enter a message here’
- Finally type git push beanstalk master (beanstalk may be origin instead)
Now that you have a basic workflow going, your files will be pushed remotely to your Beanstalk repository. Pretty neat right?
3. Get WordPress Going
The next step is going to vary depending on exactly how you like to set up WordPress. For me, I prefer to use the built in install in AMPPS, which is located on the left admin menu inside the control panel. Simply click on WordPress followed by install, select the domain (aka the domain you set up), use either a root or folder install, and the rest is pretty much straightforward.
Once the installer is complete you should be able to browse to your site. Viola! You’re not done though. There are a lot of things inside of WordPress that you do not want to copy over into your repository. Don’t forget to push your files! Some people don’t like/disagree with keeping the WordPress install in the same repo as everything else, with many opting to submodule or ignore everything other than theme files. I prefer do track everything because in the end, it makes deploying sites so much easier.
4. Wp-Config for Version Control
So now that you have your WP site synced up, we need to do something about the difference in database credentials. Although we don’t have the code on a remote server yet, it will be there soon, and we don’t want to use the same DB credentials (local servers means crappy passwords for ease of use). There are several ways to handle this by by far the best way I have found is modifying the wp-config.php file to use a local or dev file unless the site is a production server. This has the benefit of making it easier to work with multiple staging/dev servers as well as keeping extra crap we don’t need out of our code.
Below is a gist that I use when setting up my WordPress config files:
As you can see, we are simply replacing the default lines of code that define the database and wrapping them in a simple if statement that looks for a wp-local-config.php or wp-dev-config.php file and if neither are found it defaults to what is in the else statement. I use the local config file on my local system and the dev on my dev/staging environment. Those files are just a simple php block with the database information, collation, db user, etc. You’re probably wondering how we deal with the local config file since it is inside of the repository. Won’t it get staged and render our neat little hack useless? Technically if we do nothing you’d be correct however git has a handy utility called .gitignore which tells the repository to ignore that file and any changes made to it.
5. Ignoring the crap you don’t want.
Since we have a file that should not be tracked in the repository, we need to ignore it. Just like with the other commands in git you have two options, you can either use the command line or SourceTree. I find it easier to ignore files in SourceTree. It really is as simple as opening the program, looking at the unstaged files section, right clicking on the wp-local-config.php file and selecting Ignore.
If you accidentally tracked a file and need to remove it, there is also a Stop Tracking option as well, although I believe you need to remove it after doing that otherwise the file will still be there remotely in Beanstalk. Depending on your requirements there will be other files you wish to avoid tracking. Most of the time these will come in the form of images, build files using grunt/gulp, or entire directories. I strongly recommend ignoring the uploads folder in WordPress. Images are generally not supposed to be tracked as they cause repositories to get HUGE, same with Node modules and other build files.
Here is an example of a .gitignore file I’ve used on a project:
6. Set up the Remote Site and Deployment.
Everything is almost in place. The next step is getting the code into place. Since I work with WordPress mostly and because most websites today have some sort of database, you will want to copy that over first. I’ve been experimenting with WP-CLI and hope to cover that soon once I am more comfortable with it. WP-Cli is a command line for doing cool stuff with WordPress but I see it’s best use for doing a database migration as it can do URL replacement. For now though just copy your DB over however you’d like.
Once your database and dev site is set up the first thing you will need to do is log into Beanstalk. Select the repository you are creating the deployment for and press the deployment button, then you will need to create a new environment.
For this next part, I have my own process which you can feel free to copy or create your own. I will prefix the name of my deployment with the type of server it is going to such as DEV – Lukes Site. Then I will set the color of the repo to green if it is dev/staging and red if it is production. All of these exist as safeguards to help mitigate mistakes.
Next we need to decide what type of deployment to use, I always use automatic on staging and dev but Never EVER EVER use anything but manual on a production environment. This will help prevent you shipping code that you find out breaks the site.
After selecting the type of deployment you will need to select the protocol that the connection uses such as FTP, SFTP, etc. This is going to vary depending on your environment setup. Now we get to enter all of the good stuff, host names, usernames, passwords. One thing to remember is that since we are deploying to a remote server we want to make sure our code goes to the right place.
I typically open up Filezilla and SFTP to the server and check the remote path. It almost always looks like /public_html/www/siteroot or /public_html/www . This is important because sometimes the way some FTP programs connect will vary slightly and it makes sense to double check (I learned this the hard way).
With all of the information entered, you can pretty much bypass the rest of the steps, Beanstalk will do a connection check and if all things are good, you should be able to tell Beanstalk to deploy the code. As long as you used the automatic method, your code should end up on the server after the next commit or if you manually deploy.
For your production environment, the setup is exactly the same just remember to use manual deployment to prevent any Uh-Oh moments from happening. You can add as many servers to this as you’d like. There are also a lot of cool post deployment options as well that you should check out.
7. That’s a Wrap.
Whew! That was a lot to take in. I spent a good part of a year looking up various methods to handle deploying code because I grew tired of wasting time being an FTP commando. I’ve gone through just about every article I could find on this topic and while none of them were step by step guides, combining a lot of what they did in addition to my workflow specific needs, I was able to create a setup that I believe works quite well.
Hopefully this article helps others make sense of such a massive and complicated topic that is still being researched, talked, and argued about. I’m definitely far from using every best practice but this is definitely a solid starting point for WordPress version control and deployment.
I’d like to give a shout out to Issa Diao for helping me get started with Git, as well as the team at Beanstalk for being awesome folks who created an awesome tool.