Building and Deploying a PHP Application using TeamCity

Recently, vteams encountered a scenario where we had to deploy a PHP application on multiple web staging servers. Our first thought was going with the usual approach – checking out the files on both servers and manually pulling on each whenever needed. At first it worked out fine but when some server specific configuration changes were made they needed to be re-done every time we checked out of the system. This became frustrating and time-consuming as manual edits had to be made and stashed on every checkout.

R&D

We looked into PHP made tools that help with deployment and came upon Phing. It is a build tool, developed on top of Apache Ant, which makes deployment fairly easy by providing the ability to perform certain tasks in the build directory. We used it to transform configuration files and replaced 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, we still had to manually run the build scripts individually on each server. We needed to find an automatic way to do that.

Solution

It was when we searched for open-source tools deployment solutions that we came upon TeamCity. Fortunately, it had a free license that allows up to 3 projects and 20 build configurations; ample for small to medium projects.

Run bash script “Sudo TeamCity/bin/./runAll.sh start” to start the TeamCity Server, which runs on top of Apache Tomcat and port 8111. After executing this script successfully, we were able to access the TeamCity server by visiting https://localhost:8111. Following some basic configuration settings like username and password, we were able to see the TeamCity Dashboard.

For the deployment to work we had to start by creating a new project in TeamCity Administration. You can create projects through either a repository URL or by creating the project first and adding the repository later. TeamCity projects have some configuration settings that need to be filled in. General Settings include basic project settings such as name, description, and artifact paths.

We also had to associate a VCS Root with the project. It can be a Git, SVN, or any other valid VCS path. Checkout branches and other platform-specific settings are configured with the Version Control Settings of a project. As we had used a Git VCS, we had to put in a GitHub username and password for authentication. Alternatively, you can use the private key mode.

We also have to configure Build Steps to guide TeamCity on how to build and deploy the resources. For that we created 4 steps within the Steps section of the project:

1. To install composer packages after VCS checkout
2. To run phing script for transformations
3. To compress and move the resources from the build server i.e. the staging server
4. To decompress application resources on the staging server
   .

Steps 3 and 4 use SSH to run commands. Next, we had to decide when to trigger the build and deploy process. There is a Triggers section in project settings. We configured it to trigger a build every time a change is checked into VCS. This step solved the problem of having to run the build manually after each check-in.

Conclusion

All that was left was to configure the TeamCity server to run on startup. The rest of the process was automatic and every build generated a log which made it easy to look for failures during the process. So we ended up creating two projects for both servers. But a better alternative is to create one project and two build configurations; one for each server.