This week we’re happy to welcome Oskari Virtanen to our team. We’ve already briefly worked with him when he helped us with the mobile client. Previously Oskari worked on Habbo Hotel, delivering virtual sofas to teenage girls.

Oskari is our go-to guy on app security (he finished the Stripe-CTF challenge before most of us!), playing piano or snooker, advanced Git tricks, 29er sailing and .NET development. He also likes to watch funny Youtube videos, so on his first day he added support for inline Youtube video previews.

This is a guest blog post written by Brett Porter, CTO of MaestroDev, who develop DevOps orchestration tools. In this article, Brett lays out how they’ve used Flowdock as a main communication tool with distributed teams and integrated Flowdock directly into their own products.

MaestroDev is a proud Flowdock customer. Since we began using it early in the year, we have greatly improved the internal visibility of development progress, and streamlined our methods of communication – reducing the number of redundant calls and emails.

The MaestroDev product development team is globally distributed, covering 4 different timezones. Our Flowdock flow is active 24 hours a day with development information and tagged updates for each other. Whether they work face to face, or remotely, Flowdock puts all of our team members on an equal footing, catching up on important discussions as they start their day, and leaving notes about progress for team members whom they may not otherwise be able to meet with immediately.

About Maestro

We have developed Maestro, our enterprise-grade DevOps Orchestration engine, to help enable all members of a software delivery team to be more efficient and collaborative. Maestro introduces Compositions, a reusable definition of a sequence of tools, processes and infrastructure that can be automated and interacted with. Compositions encapsulate best practices and encourage consistency across projects, reducing ramp up time and silos of expertise about infrastructure. Maestro is built to take advantage of modern public and private cloud technology to dynamically scale build, test and deployment infrastructure. This reduces friction between development, QA and operations team members and reduces the wait time for necessary infrastructure. Finally, Compositions and their execution output provide a single source of truth and history about a variety of systems, where team members can keep up to date, participate in decision points, and gather feedback from integrated tools to determine future improvements.

Integrating Flowdock and Maestro for Delivery Visibility

As you can see, Flowdock complements Maestro as a dedicated information flow for communication, notifications and actions. For this reason, we have developed Flowdock integration for Maestro and incorporated it into our delivery workflows.

You can read more about the Maestro Flowdock integration in the Maestro Documentation Guides, and at the plugin’s GitHub project page.

Maestro has integration for a number of different tools available, and at MaestroDev some that we use are:

• JIRA: issue tracking and sprint planning
• GitHub: source control
• Jenkins: continuous integration and automated builds
• Apache Archiva: build artifact management
• Vagrant and VirtualBox: virtual machine for testing and delivery
• Puppet: infrastructure configuration management

With these tools orchestrated by Maestro and information streaming to Flowdock, we’re able to track a change from a JIRA ticket and a commit, through its deployment on a preview instance, automated functional tests and a complete candidate virtual machine image for distribution.

Our primary automated workflow looks like this:

• A commit at GitHub triggers a notification to Flowdock, and triggers a Composition to start the rest of the process
• Maestro ensures a suitable Jenkins job is executed to build the project and publish to the artifact repository.
• Flowdock is notified in the event of success (showing the published RPM version and build number) or failure (showing the full output and error that occurred)
• If it was successful, Maestro concurrently starts Compositions to update the preview instance, and run functional tests
• For the preview instance, we update the RPM version in the Puppet manifest, and trigger a Puppet agent run on the host. Puppet reports back to Flowdock when it is complete, and we know the preview instance is updated with the change
• For functional tests, a virtual machine is started with Vagrant, provisioned with Puppet, and then tests are run via Jenkins using Cucumber and Capybara. If any fail, a notification is sent to the main Flow.
• If the functional tests are successful, then a new virtual machine is produced and a notification sent to the main Flow.

Of course, we have many other such Compositions for sequences including releases, building and deploying Puppet modules, publishing promoted VMs to Amazon S3, and so on – all similarly integrated with Flowdock.

If you’re interested in trying Maestro out for yourself, contact us and we’ll set you up with an evaluation system and several similar pre-configured examples.

Flowdock has become the first thing I check in the morning, and one of the most useful tools I turn to throughout the day to find out what is happening, discuss a solution with a colleague, or just share a link to something fun and interesting. Our thanks go to the Flowdock team for a great product!

Two popular CI services have just implemented Flowdock integrations: Semaphore & TravisCI. Flowdock goes great together with continuous integration apps. That way the whole team can take responsibility of the state of the build. Previously, Flowdock has CI integrations for CircleCI, Bamboo, CruiseControl and Jenkins.

Special thanks to Phil Cohen for implementing the Travis CI integration.

Check out the Travis CI Instructions ➜

Check out the Semaphore Instructions ➜

Our lead developer Ville Lautanala gave a conference talk at Frozen Rails about Flowdock’s distributed server architecture and how we use Chef and ZooKeeper to coordinate a set of services.

You can find the slides from SlideShare:

Thanks to all Frozen Rails organizers, once again it was a great conference!

Grove.io, a hosted IRC service, is shutting down on October 13th. As you may know, Flowdock is fully operational via any IRC client and thus works as a fairly direct replacement.

The importer, it’s easy to use. The whole process should take only a few minutes:

1. Sign Up to Flowdock
2. Logged in to Flowdock, go to the Grove.io importer
3. Input your Grove.io credentials and follow the instructions, only the channels you select will be imported as Flowdock flows.
4. Check out How To Use Flowdock With An IRC Client.

You’ll receive e-mail notifications once the imports have been completed (should be very quick). And that’s it, you’re back in business. You’ll have 30 days to see if Flowdock works for you, before you need to pick up one of our plans.

CircleCI is a hosted continuous integration server that works together with GitHub. Setting it up for some of our Ruby-based open source projects was easy, and it figured all configuration settings automatically.

Now you don’t need those build notifications cluttering your email inbox, since CircleCI just added a Flowdock integration using our API. Check out the integration instructions and sign up for a free trial.

In addition, CircleCI offers a 10% discount for a year for the first 10 Flowdock users who sign up. Contact them for more details.

Assembla Workspaces provides wikis, ticketing, version control, milestone, time tracking and process tools. The service also has a built-in webhook feature, which we have used to integrate Assembla to Flowdock.

>> Set Up Assembla Integration

The integration produces notifications of updates in the different areas of Assembla, such as wiki edits, new tickets and so on. This is what it looks like:

At Flowdock we’re using Resque to process a bunch of background jobs: Campfire imports, analytics, payments, digest emails and others.

It works great, but I realized it’s not trivial to configure this combination to

• work with Bundler
• be reliable when servers are in inconsistent state
• restart gracefully without interrupting running jobs

So here’s how we’re doing it!

Configuring god

This is actually the part where existing documentation is correct. We have a fairly simple config/app.god, that just loads all the other files:

path = File.expand_path(File.join(File.dirname(__FILE__), 'god'))
God.load "#{path}/*.god"

Check out resque.god and resque_scheduler.god for the full configuration files, but here’s the beef:

God.watch do |w|
  w.dir      = "#{rails_root}"
  w.name     = "resque-#{resque_id}"
  w.group    = 'resque'
  w.interval = 30.seconds
  w.env      = {"QUEUES"=>resque_queues, "RAILS_ENV"=>rails_env, "BUNDLE_GEMFILE"=>"#{rails_root}/Gemfile"}
  w.start    = "bundle exec rake -f #{rails_root}/Rakefile environment resque:work"
  w.log      = "#{rails_root}/log/resque-#{resque_id}.log"
  …
end

Capistrano uses a different environment than your login shell, so it’s a good idea to define Bundler configuration here.

Configuring Capistrano

When deploying our app, we want to restart workers gracefully: they should be able to finish their on-going tasks first. Also, it needs to work whether god is up or not.

Here’s the configuration (to be included in config/deploy.rb) that I’ve found most reliable:

def try_killing_resque_workers
  run "pkill -3 -f resque"
rescue
  nil
end

desc "Restart God gracefully"
task "restart_god", :roles => :app do
  god_config_path = File.join(release_path, 'config', 'app.god')
  begin
    # Throws an exception if god is not running.
    run "cd #{release_path}; bundle exec god status && RAILS_ENV=#{rails_env} RAILS_ROOT=#{release_path} bundle exec god load #{god_config_path} && bundle exec god start resque"

    # Kill resque processes and have god restart them with the newly loaded config.
    try_killing_resque_workers
  rescue => ex
    # god is dead, workers should be as well, but who knows.
    try_killing_resque_workers

    # Start god.
    run "cd #{release_path}; RAILS_ENV=#{rails_env} bundle exec god -c #{god_config_path}"
  end
end

after :"deploy:restart", :"deploy:restart_god"

And that’s all folks!

This is a guest blog post written by Krista Kauppinen who recently started as Head of Online Marketing at Holvi, a customer of ours. She explains how Flowdock has helped her get started at her new job.

I recently started as the second nontechnical employee at Holvi, an online banking service startup that was founded in 2011. Our company is growing, but we still have everyone on the same Flowdock flow. This has been an unexpected blessing for me.

I have a business degree and I work on marketing and customer acquisition. I don’t always understand the discussions our developers have on the flow, but I’m able to see what they’re talking about and it’s in writing (so I can google unfamiliar terms!). Being able to easily get a technical perspective on customer questions and feedback by forwarding emails to Flowdock means I’ve been able to do customer support from almost day 1.

Flowdock has also been great for better understanding the pace of technical development and the relative difficulty of implementing new features and bug fixes. The team inbox that brings in data from Twitter, Zendesk and reports from our product, gives a good overall view of where we are in terms of progress.

Our team uses tagging actively, so I’ve been able to search tags like #todo, #blog or #marketing to see what’s previously been discussed on different topics. Not having to pop into the other room to ask questions and interrupt people’s workflow or send an email to whoever I suspect might know about issue X has made joining the team a lot smoother.

An added bonus of using Flowdock is seeing when my co-workers are online, as startup founders and developers often work odd hours. This has been useful for understanding their work patterns better. We have our security advisor as part of the flow, giving his point of view on what we discuss. Security is a very important aspect of building a banking product, and without Flowdock, getting information about this would be a lot more time consuming.

We also use Flowdock to share various types of benchmarking data, relevant articles, ideas we have, customer development insights and even jokes. This has helped me get to the know the company and my coworkers faster than at many previous jobs and with less effort from the others to get my caught up.

Thank you Flowdock!

In our efforts to beef up our team, we’ve hired Otto Vehviläinen, a full-stack developer with specific knowledge and experience in Backbone and Ruby on Rails development, a coffee lover and a good dude. He’s coming in to help us especially with our new web front end. He has previously worked also for one of our customers, Findery (previously Pinwheel), Flickr founder Caterina Fake’s new location based note sharing startup.