Recently, I had a scenario where i had to deploy my PHP application on multiple web staging servers and my first though was going with the usual approach, i.e. checking out the files on both servers and manually pulling on each whenever needed.
At first it worked out fine but later on, I made some configuration changes which were server specific and needed to be changed every time i checked out over at both servers. This became frustrating and time consuming as i had to manually make the edits and stash them on every checkout.
To ease it up, I started out looking for PHP make tools to help with deployment and came upon Phing (https://www.phing.info/). It is a build tool, developed on top of Apache Ant and makes deployment fairly easy by providing us the ability to perform certain tasks on our build directory. I used it to transform configuration files and replacing configuration placeholders with actual values.
While this was enough to successfully build the application on staging servers without having to tinker with the configuration files, I still had to manually run the build scripts individually on each server and i was looking for a way to automated that so that i won’t have to do that.
That is when i looked around for open source tools deployment solutions and came upon TeamCity. Fortunately, it has a free license which allows upto 3 projects and 20 build configurations, which is enough for small to medium projects.
Download and stating TeamCity was simple. I had to unzip the downloaded archive and run the following bash script to start teamcity server, which runs on top of Apache Tomcat and port 8111.
sudo TeamCity/bin/./runAll.sh start
This script runs the TeamCity server as well as the default build agent. A build agent is a service that does tha actual work of creating builds from our repository. Remember to run it in super user mode to avoid permission issues with the build agent. After the script is executed successfully, i was able to access the TeamCity server by visiting http://localhost:8111. After some basic configuration settings like username and password, i was able to see the TeamCity dashboard.
For the deployment to work i had to start by creating a new project in TeamCity Administration. You can create projects through either from a repository URL or you can create the project first and add the repository later.
A TeamCity project has some configuration settings that need to be filled in. General Settings includes basic projects settings such as name, description and artifact paths.
We also have to associate a VCS root with the projects. It can be a Git, SVN or any other valid VCS path and checkout branches and other platform specific settings are configured from with Version Control Settings of a project. As i had used a git VCS, I had to put in Github username and password for authentication. But private key mode can also be used to authenticate.
We also have to configure Build Steps to tell TeamCity about how to build and deploy the resources. For that i created 4 steps within the Steps section of the project. One for installing composer packages after VCS checkout, second for running phing script for transformations, third for compressing and moving the resources from build server, i.e. my development machine to deployment server i.e. vteams staging server and a last one for decompressing application resources on staging server. The step 3 and 4 use SSH to run commands.
Next up was the question as to when to trigger the build and deploy process. We have a Triggers section in project settings. I configured it to trigger a build every time a change is chacked into VCS. That solved my problem of having to run the buid manually each time i check in.
We can also add parameters to build which might be environment specific and run during the build steps. Artifact dependancies and other features can also be managed but i had no need to configure those settings.
That was almost all the setup required. After that i had to configure TeamCity server to run on startup and the rest of the process was automatic and every build generates a log which makes it easy to look for failures during the process. So i ended up creating two projects for both servers. But a better alternate is to create one project and two build configurations, one each for both servers.
Needless to say, having set up automatic build and deployment really saved time and helped me efficiently push out changes without having to worry about any of the configuration.
Latest posts by alexey (see all)
- Zend Soap NULL Reponse - August 29, 2018
- Quick Facts About WooCommerce - April 25, 2018
- WordPress stuck on a “Too many redirects” error loop when using SSL - January 17, 2018