CI Tools and Best Practices in the Cloud

Continuous Integration

Subscribe to Continuous Integration: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Continuous Integration: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Continuous Integration Authors: Yeshim Deniz, Mehdi Daoudi, Elizabeth White, Liz McMillan, Pat Romanski

Related Topics: Continuous Integration, DevOps Journal

Blog Post

How to Streamline the Development Process with Commit Hooks By @papa_fire | @DevOpsSummit #DevOps

There are different aspects of end-to-end processes that can help improve the adoption of DevOps principals by developers

Automation is a big part of the DevOps approach, to the point where some people (incorrectly) define DevOps exclusively as automation. While many discuss automating the deployment pipeline process for build->test->deploy, few talk about utility automation for the intermediate steps of that process.

There are different aspects of end-to-end processes that can help improve the adoption of DevOps principals by developers. There are on-call responsibilities, development-centric monitoring and process automation for developers. One of the great techniques for the latter is commit/push hooks that can be implemented as part of the version control system. Unfortunately, many people are either not familiar with pre/post commit hooks or not using them to their advantage. As a result, I thought it might be helpful to outline a few of the most common use cases for commit/push hooks that I've implemented on different projects that help to streamline the development process and reduce a number of points of failure along the way.

While it's a common practice and generally a good idea to run your test suite as part of you Continuous Integration workflow, there are certain tests that can (and should) be ran on every commit and/or push, depending on your deployment procedures and development processes. Running unit tests and linters on every changeset that is committed helps with incremental code improvement. It's worth noting that commit/push rejection is not the only response to a failed condition. Depending on the development process, the results don't have to be represented as a fatal error; they can be represented as a warning or a notice. Displaying and logging a warning message to the developer, sending an email to the dev list or posting a message into chat (more on this later) is a completely viable response. The goal here is not to have a complete test suite that dictates production readiness, but rather provide developers with an opportunity to validate and fix their code in small increments as it's being developed and committed.

For those unfamiliar with the term, ChatOps is a term coined by Github to describe the company's growing culture of "putting tools in the middle of the conversation." In layman's terms, it is a movement to keep engineers from app switching to get to incoming information and to consolidate all day-to-day notifications into a single channel, presumable chat tool of choice (Slack, Hipchat, IRC). This is not a new concept, but with the emergence of tools with built-in integration, it has become significantly easier to integrate notifications from various channels into a chatroom. You can feed alerts, emails, even notifications from third-party apps like Salesforce. So why not commit notifications? Pushing triggered commit/push notifications into a project-specific channel lets the whole team know of the changes, giving them a chance to review, comment, and discuss the changes in a single window.

If ChatOps is a new concept and is of interest, definitely read ChatOps for Dummies by Jason Hand.

Ticket management
Chances are, if you're using any of the popular ticket tracking tools like Jira or Trello you probably have them tied into your version control system already. If you don't - stop reading this and go pair them now. Even if you are not using the latest and greatest set of tools (SVN and in-house ticket tracking system, for example) you still can (and should) have these hooks implemented because having post-commit hooks tied to your ticketing system provides many utility benefits. It allows you to attach particular commits to individual tickets, manipulate ticket status and even close tickets with a commit message. This allows developers and managers to have a complete history of changes for any given ticket, making deployment and troubleshooting that much easier. It also helps to eliminate an extra step in the development process - separately going into ticketing system to update the ticket. Now, unlike testing hooks, this is an example of a rule that is recommended to be very strictly enforced. If you're diligent in using ticketing tools, rejecting any commit that doesn't reference a ticket is a good way to prevent individual commits to fall through the cracks.

Identifying and fixing the issues in production is crucial, but it requires insight not only into usage patterns and trends, but also awareness of special events or triggers (business and technical) that may be responsible for the observed behavior change. One type of such event is a productions push. Having an ability to correlate individual deployment to the monitored data points and being able to plot deployments on the same graph as the critical metrics is invaluable for troubleshooting production issues. Not only does it provide a possible root cause for the problem, it also streamlines rollback and patching procedures. Side note, having an ability and will to pipe business events like email blasts, marketing promotions, special events, etc., into the same monitoring system along with deployment events provides even deeper visibility into the state of business operation for people investigation and troubleshooting production issues.

The next time you are embarking on a new project, I recommend that you consider implementing commit/push hooks as part of your development process. The list above is not by any means complete. Once you understand the power of hooks, it will help with defining the actions for each project that is most fitting for the particular development processes. Just keep in mind the end goal - applying the safeguards and automating common repeatable processes will improve the quality of the product, streamline development, and increase your successes along the way.

More Stories By Leon Fayer

Leon Fayer is Vice President at OmniTI, a provider of web infrastructures and applications for companies that require scalable, high performance, mission critical solutions. He possesses a proven background of both web application development and production deployment for complex systems and in his current role advises clients about critical aspects of project strategies and plans to help ensure project success. Leon can be contacted at [email protected]

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.