This first post is going to touch on some of the build tools and systems we use to manage our code, our development, and most importantly, our deployment. ϳԹ’s development cycle is fluid and agile: we can deploy code at any time and have changes and updates visible to our users within minutes. (We avoid merges on Friday afternoons.) With our development cycle, we need to make sure all our code is properly reviewed and tested before we deploy to production.
Here’s a basic outline of the process all code changes must go through before going live:
I’m going to describe each step and explain why each is critical to the development process.
Code Management with Git
Version control is the most critical aspect to our development process. With Git and GitHub, we’re able to manage all of our code and work together collaboratively without (too much) conflict. GitHub is also our source of issue management, workflow, sprint planning, and pull-request (PR) review. This post isn't going to dive into the intricacies of Git, but I wanted to share what a usual cycle for a developer is, at a very high-level:
-
Product creates and assigns a ticket
-
Developer creates a branch off of Master for that ticket
-
Developer fixes the issue or implements the feature
-
Developer creates a pull request on GitHub to merge the code back into master
Pull Requests
Once a developer has finished a ticket, he or she in GitHub.
While a developer is creating a pull request, he or she asks other developers to review the code by using Github’s “reviewers” functionality. All reviewers must approve the PR before it can get merged in. This is fairly standard practice in all coding environments—fellow developers can help you identify whether you have forgotten an important piece of the ticket, made spelling mistakes, or have done anything else that might cause problems on the live site.
When creating a PR, we have two supplementary tools that we use to help with the testing and review process: Travis CI and Tugboat.
Travis CI
Travis is a continuous integration tool to help developers and teams “.” “Focus on writing code. Let Travis CI take care of running your tests and deploying your apps.” By using Travis, and other continuous-integration tools, developers can avoid merging large code changes at the end of a cycle and instead merge code more frequently to avoid conflicts and errors.
For us, Travis is a continuous-integration tool that does a few important tasks:
-
Styles code using PHP CodeSniffer as our syntax guidelines
-
Confirms all javascript has been minified and zero un-minified JS files have been pushed
-
Alerts all necessary users of errors through email alerts
We can take a quick peek into some of the benefits of using Travis.
If a build is successful, Travis passes and returns a detailed view with information such as how long the process took and any custom output from the task.
If a build fails, Travis is helpful in multiple ways. First, the PR will have a big ol’ X next to it in GitHub. That is our main clue to a failing PR. The developer of the PR will also get an email saying the Travis tests have failed. Next, it’s also pretty easy to debug why the PR failed. In the images below, you can clearly see on the Travis site that the PR failed, but you are also able to see as to why: our code failed our linter.
Tugboat
, the second tool that we use on every pull request, creates a replica site of our production (live) environment and includes the changes made in the pull request. This includes builds that match our production environment, execute build scripts, and fully merged code with master to check mergability. This way, developers and testers can see how the changes implemented interact outside of the local environment—both back-end and front-end changes. A neat feature of this is that a unique URL is generate for each PR, and that URL is easily shareable. So if we have a large feature that needs sign-off from a client, we can easily share a unique URL for others to review.
Tugboat also runs tests to make sure the PR doesn't break major features or functionalities on our site. We use and for frontend Javascript tests.
I’m not going to dive into the inner workings of CasperJS and Behat, but, on a high level, CasperJS tests any Javascript interactions, and Behat is more behavior-driven. For us, CasperJS makes sure that important elements (such as ads) are appearing. Behat ensures that editors can login successfully, that certain pages are displaying correctly, and certain flows still work throughout the site. To learn more about CasperJS, visit , and to learn more about Behat and Drupal, visit the .
As you can see, the PR is fairly extensive at ϳԹ, but it provides a quicker and more efficient code-review process. Reviewers don’t have to worry about whether the PR will break the site—instead they can focus on the actual implementation and code being changed. If either Travis or Tugboat fails, then everyone knows that the code is not production-ready.
Merging the Pull Request
Once Travis passes, Tugboat builds, and the PR has been approved by all the reviewers, the code is ready to be deployed to production. For us, we don't have one person who “pushes to master” on production everytime there is an update—that would be extremely tedious and error-prone. Instead, we use a tool called Jenkins to help with our deployment.
Jenkins Deployment
is an automation server that helps “to support building, deploying, and automating any project.” There are many use cases for Jenkins, including deployment, running tests, and building prototypes.
Jenkins does 2 main tasks for us:
-
It deploys code to Production: obviously the most important
-
It copies the Production database to our Staging environment (nightly)
For deployment to our Production environment, Jenkins makes the process streamlined while still using the same commands you’d think. There are only four steps in Jenkins that pushes the code to the live site—git checkout, git pull, git fetch, and git push—but, with Jenkins, we as developers don't have to worry about doing that ourselves. We can just click “Merge” on GitHub and the Jenkins process will be fired off.
Jenkins can also do a whole slew of things with hooks. We have it setup so a every deployment is logged in New Relic, and email/Slack alerts for every successful or failing job.
Live on ϳԹ Online
With the tools mentioned above, we’re able to develop and deploy whenever we need to. Hot fix on the weekend? As long as it passes Travis, Tugboat, and the reviewers, there is no need to wait until the workweek—that fix can go out. Need client approval for a feature? Send over a Tugboat link to get that signoff. Travis, Tugboat, and Jenkins help make our development process streamlined and efficient so that we feel confident that the best possible code is shipping out to users.
But you may be asking yourself, where does ϳԹ Online live? We use the platform to host our website and do more of the devops-like tasks. With Acquia, we don't have to worry about scaling, servers, or anything related to keeping our website up (well, besides bad code). When our Jenkins job runs, it pushes our code to Acquia, which then updates the server and the site. Acquia hosts our production website, but it also hosts our development and staging environments. These two environments provide real-world-type environments that more accurately represent what the code will be like on production. If we ever are worried about performance or how code will interact in production, we will test our code in the Acquia Dev and Stage environments before merging.
How Can We Improve?
Even though we thoroughly appreciate and enjoy our workflow, we know with the number of tools that are released each year that we need to make sure we are staying on top of the latest trends. We currently do not use a tool to measure code quality, but shows that there are a number of code-quality tools to help us write better code. Code quality can include anything from code complexity (too many if or for loops) to naming conventions. There are opportunities that we’re constantly evaluating and attempting to integrate into our backlog.
Recap
Our process allows the whole team to work cohesively and efficiently while also managing our codebase. We have thoroughly enjoyed using to test our pull requests in a replica environment, to check our code quality, and to deploy our code without any headaches. If you are in the process of starting a new project or have an existing project that is getting too heavy to manage, we recommend these tools to help take load off of the developers and allow them to build better and faster.