The Flowdock Bloghttp://blog.flowdock.com
The what's what in the Flowdock atmosphere.Thu, 26 Mar 2015 08:52:00 +0000en-UShourly1http://wordpress.org/?v=4.1.1Track and plan work in Rally, straight from Flowdockhttp://feedproxy.google.com/~r/Nodeta/~3/OFT2MU2ukCY/
http://blog.flowdock.com/2015/03/26/using-rally-straight-from-flowdock/#commentsThu, 26 Mar 2015 08:52:00 +0000http://blog.flowdock.com/?p=4570Does your team use Rally to track and plan work? Then you should definitely turn on the new integration between Flowdock and Rally. It’s bi-directional, which means that common tasks like assigning a story to yourself or changing its state can be done right from your chat. It’s also less noisy: related items are grouped […]

Does your team use Rally to track and plan work? Then you should definitely turn on the new integration between Flowdock and Rally. It’s bi-directional, which means that common tasks like assigning a story to yourself or changing its state can be done right from your chat. It’s also less noisy: related items are grouped together in inbox threads.

Rally is a leading provider of Agile software and services. Its cloud-based ALM platform provides visibility, tracking and planning for work in progress, while Rally coaches provide team training and development for better collaboration. Flowdock became a Rally company in 2013, and Flowdock Enterprise is included in the Rally Unlimited Edition plan.

Check out the video above to see Flowdock and Rally in action. Jump to your flow’s Inbox Settings to choose which Rally projects to follow and test it out.

Seamless communication in day-to-day work is crucial, both within teams and across companies. Rally and Flowdock are on a mission to make work flow smoother than before. We believe that this integration between the two tools is a step in the right direction.

If you’re interested in exploring the challenges and possibilities of cross-team communication and DevOps, good news: we’ve got a webinar series coming up. The first webinar will be held on April 15. Register here.

]]>http://blog.flowdock.com/2015/03/26/using-rally-straight-from-flowdock/feed/0http://blog.flowdock.com/2015/03/26/using-rally-straight-from-flowdock/Don’t panic! The new PagerDuty integration is here to helphttp://feedproxy.google.com/~r/Nodeta/~3/StRtQdWCOoQ/
http://blog.flowdock.com/2015/03/24/dont-panic-the-new-pagerduty-integration-is-here-to-help/#commentsTue, 24 Mar 2015 16:57:30 +0000http://blog.flowdock.com/?p=4549When your service goes down, there’s no time to waste. With sweaty palms and an elevated heart rate, you need to figure out what’s wrong, all the while communicating your status to your users. Coordinating all this is with your team complex enough – there’s no room for unnecessary actions. This is where our new […]

]]>When your service goes down, there’s no time to waste. With sweaty palms and an elevated heart rate, you need to figure out what’s wrong, all the while communicating your status to your users. Coordinating all this is with your team complex enough – there’s no room for unnecessary actions. This is where our new and greatly improved PagerDuty integration comes into play.

PagerDuty helps you resolve incidents faster. It integrates with your monitoring tools to quickly notify the right people when something goes wrong, and simplifies collaboration. When combined with Flowdock and ChatOps, teams can catch and solve problems faster than ever.

Similarly to what was done with our GitHub, Trello and Zendesk integrations, we’ve rewritten our PagerDuty integration to take advantage of some awesome new integration features:

Activity messages related to one incident will now be grouped together into one thread. This means a cleaned up inbox, and the complete history of an incident in one screen.

PagerDuty incidents now include a color-coded status label in the team inbox. See whether an incident is new, acknowledged or resolved at a glance.

Acknowledge or resolve incidents right from Flowdock! When things go wrong, you should focus all your efforts on figuring out what’s wrong. It’s now possible to quickly acknowledge the issue from the tool that you’re already using to discuss the problem with your teammates.

You can start using the new integration today. Setting it up is simple: open your flow’s Inbox Settings and click on Add new next to PagerDuty. If you’ve been using the old integration, it’s a good idea to disable it from PagerDuty before upgrading.

]]>http://blog.flowdock.com/2015/03/24/dont-panic-the-new-pagerduty-integration-is-here-to-help/feed/0http://blog.flowdock.com/2015/03/24/dont-panic-the-new-pagerduty-integration-is-here-to-help/Flowdock Enterprise is here. Get it today.http://feedproxy.google.com/~r/Nodeta/~3/vqnEfv7lv4s/
http://blog.flowdock.com/2015/03/17/flowdock-enterprise-is-here-get-it-today/#commentsTue, 17 Mar 2015 15:23:08 +0000http://blog.flowdock.com/?p=4540A few years ago, we set out to improve communication practices within individual teams. Distributed teams were becoming the norm, and e-mail inboxes everywhere were getting cluttered with notifications from a growing number of web-based tools. If you wanted to reach your team members, you would crank up the ol’ email client. Fast forward to […]

]]>A few years ago, we set out to improve communication practices within individual teams. Distributed teams were becoming the norm, and e-mail inboxes everywhere were getting cluttered with notifications from a growing number of web-based tools. If you wanted to reach your team members, you would crank up the ol’ email client.

Fast forward to 2015. Flowdock is a powerful tool that helps teams and organizations introduce a big positive change in their communication practices. It reduces the need for meetings by allowing you to communicate across the organization when needed, not during the next sync meeting or free calendar slot. The team inbox in Flowdock receives all activity notifications from your team’s tools, keeping your personal email inbox a much happier place.

Today, we’re launching a new product: Flowdock Enterprise. Flowdock Enterprise includes all the wonderful qualities of Flowdock, and builds on top of it with enterprise-grade security features, improved administrative controls and full enterprise user management integration, including single sign-on and automatic provisioning and deprovisioning. We are launching with out of the box support for OneLogin and Okta, and support any SAML 2.0 compatible SSO provider.

Other highlights include custom data retention policies (choose exactly how long discussion data should be stored for) and an even stronger enterprise level security framework based on the NIST 800-53 Rev 4 industry standard. See our enterprise features page for a comprehensive list. We will keep growing the feature set of both Flowdock and Flowdock Enterprise based on your feedback. We currently have lots of good stuff in the pipeline, specifically notification improvements and configurability.

How to buy

Included in Rally® Unlimited Edition

Flowdock Enterprise is included with each Rally Unlimited Edition license. Unlimited edition customers are entitled to purchase Flowdock Enterprise Add-On seats at a lower price point – a great opportunity to bring more folks into the loop.

If you’re a Rally Unlimited Edition customer and would like to get started with Flowdock, contact your Rally account manager.

Feedback wanted!

Let us know what you’d like to see next in Flowdock Enterprise (and, of course, Flowdock). We’re counting on you to help us make it better. Any opinion, idea or half-formed thought you send to support@flowdock.com will be eagerly read, carefully considered and earnestly answered!

]]>http://blog.flowdock.com/2015/03/17/flowdock-enterprise-is-here-get-it-today/feed/0http://blog.flowdock.com/2015/03/17/flowdock-enterprise-is-here-get-it-today/Flowdock for Windows out now!http://feedproxy.google.com/~r/Nodeta/~3/_2mZz_nQMu8/
http://blog.flowdock.com/2015/03/03/flowdock-for-windows-out-now/#commentsTue, 03 Mar 2015 12:53:23 +0000http://blog.flowdock.com/?p=4524It’s a glorious day for all Windows users everywhere. Flowdock for Windows, our desktop app for all the Microsoft enthusiasts, is now available. It includes many features you would expect from a desktop app: Desktop notifications Notification count badge on the taskbar icon Automatically launch the app when Windows starts (if preferred) Native keyboard shortcuts […]

It’s a glorious day for all Windows users everywhere. Flowdock for Windows, our desktop app for all the Microsoft enthusiasts, is now available. It includes many features you would expect from a desktop app:

The Windows app has been in closed beta for some time, during which all critical bugs were ironed out. Many thanks to everyone that took part in the beta! If you still run into issues or have improvement suggestions, we’re still looking forward to hearing your feedback at support@flowdock.com.

]]>http://blog.flowdock.com/2015/03/03/flowdock-for-windows-out-now/feed/0http://blog.flowdock.com/2015/03/03/flowdock-for-windows-out-now/Fight inbox spam with the new Trello integrationhttp://feedproxy.google.com/~r/Nodeta/~3/S71vqlT640g/
http://blog.flowdock.com/2015/02/04/fight-inbox-spam-with-trello-integration/#commentsWed, 04 Feb 2015 13:16:01 +0000http://blog.flowdock.com/?p=4494Hot on the heels of our improved GitHub and Zendesk integrations is an upgrade to another popular Flowdock integration: Trello! All updates to a Trello card will now be grouped into one thread within a team inbox item. Hooray for less inbox spam! You can see the name of the list that the card belongs […]

All updates to a Trello card will now be grouped into one thread within a team inbox item. Hooray for less inbox spam! You can see the name of the list that the card belongs to from your inbox, helping you stay up to date at a glance. You can also add yourself to a card or move a card between lists, right from Flowdock.

To start using the new integration, simply add Trello as an inbox source in your flow. If you already have Trello set up, you should see an instruction on how to upgrade.

We’re currently hard at work upgrading our most popular integrations, so expect some more updates in the near future. If you’re the maintainer of an existing Flowdock integration or would like to integrate a new service with Flowdock, be sure to check out our new integration guide for instructions on how to take these new features into use – your users will surely thank you.

]]>http://blog.flowdock.com/2015/02/04/fight-inbox-spam-with-trello-integration/feed/0http://blog.flowdock.com/2015/02/04/fight-inbox-spam-with-trello-integration/GitHub in Flowdock: Better than everhttp://feedproxy.google.com/~r/Nodeta/~3/iYA1nVsMgmU/
http://blog.flowdock.com/2015/01/29/github-flowdock-better-ever/#commentsThu, 29 Jan 2015 15:46:55 +0000http://blog.flowdock.com/?p=4481Even though we see all kinds of teams using Flowdock these days – from execs to customer support – GitHub is still, by far, the most popular Flowdock integration. We are huge fans of it on the Flowdock team as our software development life revolves around pull requests. We like to think that the GitHub […]

Even though we see all kinds of teams using Flowdock these days – from execs to customer support – GitHub is still, by far, the most popular Flowdock integration. We are huge fans of it on the Flowdock team as our software development life revolves around pull requests.

We like to think that the GitHub integration has done an awesome job of giving you an idea of what’s happening in GitHub at any given time. But when you’ve wanted to see the state and history of a specific pull request, you’ve had to jump over to GitHub. Not a big deal, but when you’re in state of flow, every second of concentration counts.

Create and assign PRs from Flowdock

What’s more, our new concept of team inbox actions allow you to interact with GitHub directly from Flowdock: you can create PRs and assign them to yourself. Flowdock isn’t trying to replace GitHub’s excellent pull request UI – instead, we’re determined to offer ways to make teams’ workflows faster by allowing them to perform simple, common actions right from within Flowdock.

Turn it on today!

To start using the new integration, there are a couple of simple steps:

If you’ve already connected GitHub repositories to your flow, you will see a deprecation warning in your Inbox Settings. Follow the instructions to upgrade to the new version.

Otherwise, open your flow’s Inbox Settings and add a new GitHub source. You’ll start using the new integration automatically.

The setup process will ask you to grant Flowdock access to your GitHub repositories. This is used to get a list of your repositories, for setting up webhooks, and for the inbox actions. We’ve had some good early feedback from customers saying that they need to be able to set up the integration without exposing access to their GitHub repositories. If you’re one of them, fear not: we are currently in the process of coming up with a manual setup process that doesn’t require such rights.

Addendum, February 10th 2015: It is now possible to configure your GitHub webhooks manually. Read the instructions on how to set them up.

For integration partners

Is your product on the growing list of Flowdock integrations (80+ today)? We’re sure your customers would love to see these new features (grouped events, inbox actions) in your integration. Take a look at our new integration guide for instructions on how to get started.

]]>http://blog.flowdock.com/2015/01/29/github-flowdock-better-ever/feed/0http://blog.flowdock.com/2015/01/29/github-flowdock-better-ever/Tackle support tickets with our new two-way Zendesk integrationhttp://feedproxy.google.com/~r/Nodeta/~3/Y-pBylrA1iA/
http://blog.flowdock.com/2015/01/20/new-flowdock-zendesk-integration/#commentsTue, 20 Jan 2015 16:11:44 +0000http://blog.flowdock.com/?p=4365Early morning. Taking care of support tickets. Got nine in the queue. One difficult and eight that I can handle easily. Asked the rest of the team about the difficult one in our flow – could be a bug, but where? I’m not sure, but the flow usually knows. Next up, the eight easy ones. […]

Early morning. Taking care of support tickets. Got nine in the queue. One difficult and eight that I can handle easily. Asked the rest of the team about the difficult one in our flow – could be a bug, but where? I’m not sure, but the flow usually knows.

Next up, the eight easy ones. Handling them with a smile on my face. The early-bird engineers have started flowing in, and embrace the difficult bug challenge. Turned out to be a wrinkle in our notification system. My teammate Joe replied to the requester himself, signing it “Joe / Engineer”. His fix is already in QA. Looking good.

“No tickets in this view.” That was fast.

Tackling support tickets is incredibly effective as a team. Tickets that appear in your team’s inbox are a great starting point for discussions related to the problem, or the coordination of who’s going to handle it. Making your users’ feedback visible for everyone – especially your development team – has the added benefit of keeping a collective finger on your users’ pulse, helping you guide product development in the right direction. The whole Flowdock team handles support, which has been an extremely beneficial practice.

Today, we’re kicking off a new wave of integrations. We’ve been working on these for a long time, and are pleased to launch with Zendesk, our most popular customer support tool. Let’s look at what’s new.

Related activities grouped together

All interactions related to one support case are now grouped into one thread. This means that customer messages, ticket assignments, status changes, comments on Zendesk and discussions on Flowdock are all visible as one chain of events. This allows you to easily follow the whole history of a customer interaction.

As long as the activities are related to the same Zendesk ticket, we now group consecutive activities in the team inbox as well. Less noise for all!

Visible status

Each Zendesk ticket has a state: new, open, pending or solved. These states are now visible (with color-coding) right from the team inbox. This helps the team quickly react to new or open tickets.

Two-way integration

This is big: we’ve also added the ability to perform common actions right from within Flowdock! Assign tickets to yourself or change the state of a ticket with a single click. There’s tons of potential with bidirectional integrations, so expect some awesome new features based on this.

Next up: GitHub, Rally, Trello, Pivotal Tracker and more

The new Zendesk integration can be enabled by anyone who has admin access to your Zendesk subscription.

We’re currently working on updating other popular integrations (such as GitHub, Rally, Trello and Pivotal Tracker) to the new integration platform. We’ll keep you updated.

If you happen to maintain a Flowdock integration, we’d love to see you take advantage of our new integration platform. Your users will surely be delighted. Read our integration guide, or send a message to support@flowdock.com if you have any questions. We’ll help you be among the first partners who takes advantage of these new awesome features, and will make sure our users hear about it.

Disclaimer: We do not recommend the use of tobacco products during or outside the proceedings of your support process.

]]>http://blog.flowdock.com/2015/01/20/new-flowdock-zendesk-integration/feed/0http://blog.flowdock.com/2015/01/20/new-flowdock-zendesk-integration/The benefits of not having a support teamhttp://feedproxy.google.com/~r/Nodeta/~3/PXsfNk03gkM/
http://blog.flowdock.com/2015/01/16/benefits-not-support-team/#commentsFri, 16 Jan 2015 13:17:13 +0000http://blog.flowdock.com/?p=4436On the Flowdock team, everyone does customer support. We don’t have dedicated support people. The people who respond to support@flowdock.com are the ones who develop, market and lead Flowdock. This is surprising for many. We often receive requests to “pass this message on to the development team”. Shouldn’t a software developer spend their time building […]

]]>On the Flowdock team, everyone does customer support. We don’t have dedicated support people. The people who respond to support@flowdock.com are the ones who develop, market and lead Flowdock. This is surprising for many. We often receive requests to “pass this message on to the development team”.

Shouldn’t a software developer spend their time building a better service, not handling customer support? More generally, shouldn’t people spend their time on what they were hired to do, and not waste time doing support? These are common thoughts that lead to the creation of dedicated support teams, outsourcing customer support. We find this to be a detrimental, even dangerous practice. Having the whole team do support is crucially important for many reasons, outlined below.

Feel for your users

Increased empathy for your users is the most obvious benefit. There’s no better way to understand users than by having a constant line of communication open with them. Even if you dogfood your own product (as we do, heavily), you’re still looking at it from one perspective. What seems like a minor bug may be extraordinarily frustrating for some, while a small new feature can be tremendously beneficial for others.

Having the whole team interact with customers leads to a surprising benefit: a shared understanding. We rarely have disagreements about what we should work on next – the team simply knows which features will provide the most benefit for our users.

Communicate with the ones responsible

When you’re solving a problem with a user, you often have to dig into parts of the product that you aren’t familiar with. You might have intricate knowledge about how your product’s integrations work, but be clueless about the signup process. When you start helping a user who is having problems signing up, you force yourself to expand your expertise. This leads to everyone on the team having a better understanding of the product as a whole.

This is great for users as well. When they have an issue, the foremost experts on the product – the people who designed, built and thoroughly understand it – are the ones answering. Instead of having to look for answers or delegate problems (aka. handovers, see below), the responder often provides a knowledgeable answer, quickly. And if not, they can ask for help in the team’s flow.

We’ve received lots of positive feedback about our customer support. Users appreciate being able to talk to the ones responsible for a product.

Chat as a bug tracking system

Unless a lot of effort is spent grooming its contents, the value of a formal bug tracking system decreases over time. The volume of bugs that are no longer relevant grows gradually, making it harder to pick out the important ones.

Our current process for handling bugs is lightweight while still ensuring that important and easy bugfixes get delivered. When we encounter a new bug, a quick triage takes place. If the severity is high, it’s fixed as soon as possible. The bug is reported in our flow with a #bug tag and a @mention of the person who has agreed to fix it. Once fixed, the #bug tag is removed. Low severity bugs with trivial fixes are fixed right away, while the rest of them are mentioned in our flow. If a low severity bug starts affecting many of our users, we will see more mentions of it, increasing its severity.

Because the development team handles support, this type of lightweight bug handling is possible. Customer support is an important input when assessing the severity of bugs – important bugs will rear their head via support messages.

Handovers suck

Finally, not having a dedicated support team removes at least one handover. When a support person handles a case by escalating it to a developer or team, they can (correctly) feel that they’ve done their part without actually resolving anything. This is in no way the fault of the support person – they’re acting as they should. But it’s an indicator of a badly designed system.

If you design your customer support system to include handovers – points at which responsibility is absolved – you’re setting users up for disappointment. In addition to delaying resolutions, each handover throws away the rapport that was painstakingly built between a user and a support person.

There are, of course, situations when a handover is necessary. An example is when a team member is unable to fix a reported bug by themselves. We’ve tried tackling this by making the original responder responsible for finding the person to take over the problem – hence the @mention that gets added to the bug report in our flow.

Scaling support without a support team?

Since our user base grows at a faster rate than the Flowdock team, this presents a problem: will we be spending too much time handling support at some point? We could hire people to take care of the so-called level 1 support cases.

Unfortunately, this might take away most of the benefits outlined above. Easy support cases are our background hum. They don’t take up a lot of the team’s time and effort, yet provide us with valuable insight into our users: what aspects of Flowdock they love and which features are causing confusion.

We haven’t come up with a silver bullet solution for this challenge. The end result will most likely be some sort of hybrid approach, with the Flowdock team still continuing to handle support. In addition to scaling support, having dedicated level 1 support people does provide a few other benefits: easy issues are handled quickly, on all time zones.

For now, we will continue handling support ourselves while building a user-friendly service that is as bug-free as possible, minimizing tricky support requests. When the scalability of our support becomes an issue and forces us to evolve our process, we’ll be sure to share the outcome on our blog.

]]>http://blog.flowdock.com/2015/01/16/benefits-not-support-team/feed/0http://blog.flowdock.com/2015/01/16/benefits-not-support-team/The meeting is starting! Do we have a /Room?http://feedproxy.google.com/~r/Nodeta/~3/uYVhAfI1jkc/
http://blog.flowdock.com/2014/12/16/flowdock-video-calls-with-room-integration/#commentsTue, 16 Dec 2014 15:22:53 +0000http://blog.flowdock.com/?p=4418Want to talk face to face with people in your flow? Thanks to our new integration with Room, it’s now easier than ever: just enter /room in your flow (or 1-to-1) to start a video call. As long as you have either Chrome or Firefox installed, no additional software or signing up is required. Up […]

]]>Want to talk face to face with people in your flow? Thanks to our new integration with Room, it’s now easier than ever: just enter /room in your flow (or 1-to-1) to start a video call. As long as you have either Chrome or Firefox installed, no additional software or signing up is required.

Up to four people can join in on a Room video call, including people outside your flow. You can also share your desktop by clicking on the screen sharing button on the left side of your screen. And best of all, it’s completely free!

]]>http://blog.flowdock.com/2014/12/16/flowdock-video-calls-with-room-integration/feed/0http://blog.flowdock.com/2014/12/16/flowdock-video-calls-with-room-integration/ChatOps: Everything about deployments right inside your chathttp://feedproxy.google.com/~r/Nodeta/~3/jR6vWahjDoU/
http://blog.flowdock.com/2014/11/11/chatops-devops-with-hubot/#commentsTue, 11 Nov 2014 15:27:30 +0000http://blog.flowdock.com/?p=4333Flowdock is a sophisticated application made up of dozens of individual services. Keeping it up and running with no downtime while practicing continuous delivery is no easy task. We recently identified some pain points in our deployment process – such as limited visibility into the current state of our application – so we set out […]

]]>Flowdock is a sophisticated application made up of dozens of individual services. Keeping it up and running with no downtime while practicing continuous delivery is no easy task. We recently identified some pain points in our deployment process – such as limited visibility into the current state of our application – so we set out to improve it by turning to ChatOps.

Our goal was to be able to do something like this:

Below is a summary of what we learned, our solution and results.

Improving deployments with ChatOps

GitHub has been pioneering ChatOps – a way to automate most ops-related tasks with a chat bot. They’ve also done some awesome work building components related to the workflow, Hubot being the most popular example. We’ve had Hubot running in our own flows for a long time, but he’s mostly been idle, waiting for something meaningful to do.

We decided to build our new deployment process based on Hubot and ChatOps. This is what we had in mind:

All deployments are initiated in Flowdock by chatting with Hubot. This provides visibility into who is deploying what, in real-time. Additionally, the chat transcript functions as an audit log.

Hubot creates deployments using the GitHub deployments API. This leads to a single, easy to access source for all information about deployments.

Heaven receives webhook events about initiated deployments and performs the actual deployments using capistrano. Only the deployments server needs SSH access to our production application servers.

The status of deployments are sent back to Flowdock, making them visible and searchable for everyone.

Additional features included:

Automatic deployments to our QA environment when a master branch is updated and our builds succeed and tests pass.

Automatic checks that all environments are up to date with master.

The workflow, component by component

The entire process has quite a few moving parts:

First we need a Hubot to chat with

Orchestrating everything with hubot-deploy

Hubot-deploy is the first deployment-related part of the process. It defines the available deployment targets and provides the necessary Hubot commands to initiate deployments. The script is configured with a simple apps.json file that tells Hubot about the deployable applications, their repositories and how they should be deployed. When it’s up and running, just start deploying:

This creates a deployment in the corresponding repository. As an added bonus, it will check for a green commit status (build is successful) and will even automatically merge the master branch into the branch being deployed if the branch is lagging behind. Additional features include the ability to specify a different deployment command (deploy:migrations), forcing a deployment even if the build is failing (deploy!), deploying a branch (app/branch) or specifying the target environment or servers (to production/frontend).

Deployments API to glue everything together

GitHub’s deployments API is still in beta, but it can already do many cool things. The API acts as glue that holds the process together, but it has other benefits as well: having all of our deployments recorded in the GitHub API makes them easily accessible for other components, and allows us to gather better status information across our infrastructure.

A webhook in GitHub posts to our deployment server whenever a deployment is created. The deployment server then takes over the process and updates the state of the deployment in GitHub as it progresses.

Heaven for performing the deployments

Heaven is the deployment server that performs the actual deployments. It listens for GitHub deployments and deployment status webhooks, and executes the deployment tasks as background jobs. Heaven supports multiple deployment providers, meaning you can use it to deploy to Heroku or by using capistrano or Fabric, to name a few options.

Since Heaven is designed to be run in Heroku, the capistrano provider was a bit limited. We created a capistrano provider that supports both cap2 and cap3 through the use of bundler. It’s now included in Heaven. Once we had Heaven up and running, we needed to strip out most of our custom capistrano configurations since Flowdock notifications and requirements for deployments were now handled elsewhere. Our capistrano recipes ended up being significantly leaner.

We also reworked the Flowdock notifier to take advantage of our most advanced features. Heaven now supports our new, enhanced (beta) Threads API. All the activities and discussions related to a single deployment now appear in one thread, with the current status of the deployment updated in real-time at the top of the thread.

The deployment updates are displayed in the team inbox, along with the latest state of the deployment. Deployment updates no longer clutter up your chat:

Of course, all your deployments are available via search:

This comes in handy when you’re debugging whether a code change caused a production issue.

Deploy automatically with Hubot-auto-deploy

Hubot-auto-deploy provides the necessary commands to configure automatic deployments. All of our applications are now automatically deployed to our QA environment by the GitHub autodeploy service when the master branch is updated and has a green commit status. Using Hubot-auto-deploy made configuring the automatic deployments really simple, and also lets us disable them when we want to run other branches in QA for prolonged periods of time.

Hubot-deploy-status for querying rich deployment status information

Hubot-deploy-status is a Hubot script that lets us see how our deployed builds differ from the repository’s master branch. We use it to communicate what has not yet been deployed:

The script also runs automatic checks from time to time. Our production environment is checked every morning for pending commits and the results are posted to our flow’s inbox:

We want to encourage our team members to deploy code often and in small batches. There are three main reasons for this: improvements should be pushed out to users as soon as possible, rollbacks are less risky, and tracking down bugs and performance issues is easier if you don’t deploy ten different features at once. If Hubot knows your GitHub username, it will tag you in the message when some of your commits are pending, alerting you with a Flowdock notification.

Expanding Hubot usage

Now that we’re using Hubot more and more as an important part of our workflow, we have started expanding its capabilities. It’s now possible to query the status of our applications in different environments (service masters / DB states…) using our hubot-command script and to fetch graphs from Graphite, right from within our development flow.

As part of our effort to build all of this, we also gave our APIpackages and other components quite a bit of love. Be sure to check them out if you want to build custom Flowdock integrations.

Future development

We’ve only been using this workflow for a short time, but it has already greatly helped our continuous delivery process. As can be seen, deployments are up by 100-200%:

However, there’s still lots to do. Our new API is already aware of external data (context), so we could do things like:

Just say “ok deploy” to the deployment nagger message, and Hubot automatically starts the pending deployment.

Retry failed deployments by just commenting “retry” in a deployment thread.

Unfortunately, both of these would require forking lots of code in Hubot and related scripts since most of the chat networks that Hubot supports don’t provide this rich context.

The end result?

We’re big fans of continuous delivery. We deploy code to production multiple times a day, but before these new tools, we felt our deployment process had some shortcomings:

Even though we received notifications about finished deployments in Flowdock, we didn’t get visibility into when deployments were started (and by whom). Now we instantly see when deployments start and who started them, leading to deployment-related discussions in context. Deployment information is no longer siloed away in command-lines and terminals.

When using capistrano to deploy, only those who had SSH access to our production environment could deploy. We’ve now been able to decouple being able to deploy from production access, which is great for security.

We had a few issues when nobody noticed that a component was lagging behind master in production by a few days. With automatic deployments to our QA environment and automatic daily status updates for each component, we can make sure everything’s running with the newest code.

Information about deployments was hidden in our application servers, making it hard to access. With several dozen individual services that make up the full Flowdock application, coordinating the whole was starting to become difficult. With the deployment statuses in GitHub, we can build better tooling and have real-time visibility into what’s currently running.

All in all, the improvements made it easier for us to manage the entire stack and removed a lot of manual work. An even better benefit is the reduced mental overhead thanks to being able to trust that every service is up to date. Deploying is also very easy: even our UX dude feels comfortable deploying code to production without the stress that comes with typing (possibly disastrous) commands into a production console.

Are you interested in taking this setup to the next level? We happen to be looking for a DevOps-minded person to join our team in Helsinki!

Big thanks

All of this wouldn’t have been possible without atmos, who has developed most of the components that we use, and the entire GitHub deployments API team. A big “Thank You!” to all of you is in order!