Whether building a product from scratch or doing a simple redesign, it’s important that our development work happens in the background.
Why in the background? For many reasons. The first that comes to mind is so we don’t show our work to the world while it’s still in progress. Another, and far more worrisome, is so we don’t impact anything on the client’s live Production site.
A simple way to get around some of that is by doing development work in a local environment. But many times the client needs to be able to see the progress that’s being made for their own eyes. Or may need to start adding content for the site or application on their own. They can’t do that if you’ve got everything locally.
To address all these issues, we use a web accessible Staging environment for every project. And because our local environments are in sync with Staging, we can show our work to the client without the fear of having anything we do (or they might do) impact a live site.
Improving our workflow with build automation tools
We’re a small remote team. As such, everyone pitches in during a project build. That’s why we prefer our designers and developers to have a more “hybrid” skillset. Designers should be able to code and developers should be familiar with design tools like Sketch.
A designer waiting on a developer to update a client’s site leads to an unnecessary bottleneck.
But while having hybrids on our team is great, there is an inevitable tipping point. There are times in a project when one of our designers can find themselves in feeling a lack of confidence. Handling build compiles or accessing a server’s command line, comes to mind. This can lead to a bottleneck.
For example, the client might need a small change that is simple for a designer to make locally. However, pulling those changes on to a staging server so the client could see them would require us to wait on a developer to run the commands.
We tried various automated deployment solutions in the past with varying degrees of success. In the end we found ourselves reverting back to doing things by hand. It was tedious, but more reliable.
As we got busier though, this became less of an option because the bottleneck kept getting worse. Designers were waiting on developers. Developers were being interrupted with small frequent changes. Nobody was happy.
What we needed was a reliable build automation solution that integrated with the way we work.
Enter Buddy, a build automation app that makes our lives a lot easier
At the start of a project last year, one of our developers mentioned that he wanted to try this new app called Buddy. He had used it on a personal project and found that it was a great way to push code to a server.
At its core, Buddy allows you to run your apps in disposable sandbox environments and automates cloud and server deployments with ease.
Buddy’s deployment pipelines were exactly what we had been looking for. Not to mention it’s easy to use and well designed interface was perfect for our less technical team members.
The app allows you to create a project that can be filled with multiple pipelines. Which for us, is mainly a Staging pipeline and Production pipeline.
Add a new pipeline
Buddy integrates with our GitHub account and allows us to create a pipeline that ties in with a particular branch in a given repository. It has options to 1) trigger the pipeline with manual execution, 2) listen for a push, or 3) run recurrently (ex. every night at 6pm for example).
Within each pipeline you configure actions that you want to run once it’s triggered. There are endless options including transferring data to a server, running commands, executing scripts, building an image, and more.
Add new actions
How we use Buddy
For most of our projects, we configure actions for both our Staging and Production servers. For Staging we have Buddy listen for a push on our Staging branch. Then it automatically connects to our server with the proper credentials and executes a [html]git pull[/html] to transfer the latest build.
We always make sure that someone is watching and ready to act in the event of an issue.
Production is set up in almost the same way, but since Production is typically more sensitive, we set the trigger to manual. That way someone has to go in and manually trigger the pipeline when we launch or have significant updates to make. We always make sure that someone is watching and ready to act in the event of an issue.
Another great part about Buddy is that it supports over 30 integrations. They have an API that allows them to integrate with services including GitHub, Slack, Shopify, and S3 just to name a few.
Since we find ourselves in Slack quite a bit, we’ve integrated Buddy so that we can run production deployments for 45royale.com right from there. Once we have a discussion in our [html]#development[/html] Slack channel that our Staging changes are approved, one of our admins types [html]’deploy /run'[/html] which triggers the Buddy Production pipeline of our master branch. And just like that our changes are live on Production!
Run the pipeline
We’ve been super happy with our improved build automation workflow. In fact, we’re constantly finding new ways to make things more efficient with Buddy.
If you’re not sure how Buddy would fit in to your workflow and environment, I’d suggest browsing through the Guides on their website. They have a great collection of articles that help you through various services and workflows that make using Buddy so powerful.
Have you used Buddy before? If not, what tools do you use to eliminate bottlenecks in your workflow? We’d love to hear more about your experience and/or thoughts in the comments below!
