Moving Data Centers with Chef

Moving data centers is scary, make it less scary with Chef, U-Haul not included.

@mtldo + @cfortier at #chefconf2014

At ChefConf 2014 this year, Chris Fortier and I had the privilege of presenting on the challenges of moving from a physical data center to the cloud. Beyond the move, we had to move towards more automation and a hands off approach to managing servers. This meant learning Amazon Web Services in depth and getting Chef onto every one of our machines. The result of our work was a library of cookbooks that could reliably work in three distinct locations: physical servers in Rackspace, laptops in our SoHo office, and cloud instances in AWS. As we developed these cookbooks we gradually improved our process and testing techniques. We reached a flow that kept cookbooks tested and trustworthy no matter where we launched. This also gave the whole team visibility into system changes that would have been easily missed otherwise.

Read more →

Developer’s Toolkit: Chris Fortier

This post is part of a series where Behance developers talk about the various tools they use to get things done and make ideas happen.

fortier1. Who are you and what do you do at Behance?

Hello, I’m Chris Fortier and I am the Lead Quality Engineer at Behance. My main responsibility is to help guide the Quality Engineering Team so that we can figure out how to test all the various aspects of our websites. I’ve been on the team for a year now (I know, I’ve slacked off on writing this post) and I’ve been involved in quite a few projects. The first major project that I worked on was an automated process to build a replica of our production environments so that we can have a more effective development and testing process. These environments are built on VirtualBox and OpenStack virtual machines. For the past several months I’ve been working very closely with the DevOps team as we adopt Chef and standardize our infrastructure as code. Looking forward to 2014, we are in the process of a complete overhaul of our testing infrastructure and busy trying to figure out how to build a Continuous Deployment process. Stay tuned for details.
Read more →

Distributed Test Projects in Jenkins

If it’s a feature, your pull request had better have tests.

That’s our mantra here at Behance. We’ve found that this philosophy is probably one of the most reliable ways to enforce a strong and stable growth in our applications. But what happens when this is taken seriously in a team of ten developers? Twenty? More? Every week our team juggles multiple features, improvements and hot fixes, usually between multiple applications, so new tests are constantly making their way into builds. Our team is also constantly growing so the number of tests that make their way into master on a daily basis keeps on increasing. This became a monster of a problem fast, because our test build times started to increase rapidly and our continuous integration (CI) server became overburdened with queued tests that needed to be run.

Read more →

Developer’s Toolkit: Sean Dunn

This post is part of a series where Behance developers talk about the various tools they use to get things done and make ideas happen.

1. Who are you, and what do you do at Behance?

Hi There! I’m Sean Dunn and I spend my days at Behance hacking on Javascript with Dave Stein and Alex Lee. Over the last few months I’ve worked on everything from modularizing our front-end codebase to new feature for our users to internal tools that help us get our job done. My newest obsession is improving how we test our site functionality across multiple browsers and Operating Systems.

Read more →

Developer’s Tookit: Manny Toledo

This post is part of a series where Behance developers talk about the various tools they use to get things done and make ideas happen.

1. Who are you and what do you do at Behance?

Hello everybody, I’m Manny Toledo a Devops Engineer here at Behance. My main goal is making sure that Behance always offers the best experience possible to everyone in the community. Beyond that I help implement and build tools to make our lives easier on the development and infrastructure side of Behance. My new shiny toy to accomplish that is Chef.  It is a configuration management tool that lets us use code to describe what our infrastructure should look like and push those rules out to each server.  This also allows us to commit our configuration to git and keep versions of infrastructure changes.  Overall some really awesome stuff for managing a servers in bulk.

Read more →

Developer’s Toolkit: Dallas S. Simpson

This post is part of a series where Behance developers talk about the various tools they use to get things done and make ideas happen.

1. Who are you, and what do you do at Behance?

I’m Dallas S. Simpson and I am the Database Administrator (DBA) here at Behance. I’m responsible for all things MySQL related from making sure our databases are online, consistent and running as fast as possible to designing schemas, writing queries and making sure the code is interacting with the databases in the most efficient manner possible. I love databases! I’ve been working in tech for over 13 years now in various capacities and databases have always been the one thing that never cease to interest me. Originally I’m from Philadelphia, PA but moved to the East Village in New York in November of 2012 to come work here at Behance. When I’m not working I can found taking in live music, enjoying small batch bourbon, hanging out with my dog or underwater SCUBA diving.

Read more →

Deployment with Scarlett ( Hubot + HipChat + Nodejs + CoffeScript + Phing )

Clase Premier / Scarlett Johansson by César Moreno on Behance

Clase Premier / Scarlett Johansson by César Moreno on Behance

Here at Behance, we deploy a lot of code, very VERY frequently. We are constantly adding new features to our applications, hotfixing bugs, and changing things to give everyone a better user experience.

The Problem:

Currently, we have 3 operations engineers who have the credentials to build our applications to our pre-production and production environments ( Myself, Ko Uchiyama, and Chris Henry ). If none of us are available for whatever reason, changes don’t get pushed. At the same time, if we ARE available, on a really bad deployment day we can receive anywhere from 12-30 requests to push changes which can REALLY interrupt our work flow or weekend ( Especially mine since I’ve become the “main build engineer guy” lately). How can we make this workflow better?

The Solution:

Build a robot to do it for you! Duh.

Read more →

Developer’s Toolkit: Ko Uchiyama

This post is part of a series where Behance developers talk about the various tools they use to get things done and make ideas happen.

1. Who are you, and what do you do at Behance?

Hello all, I’m Ko Uchiyama and I am the Head of DevOps over here at Behance.  My main responsibilities are to make sure all of our systems are running smoothly – servers, databases, networks, etc.  I also do lots of automation work with bash scripting and Puppet.  I find it really helpful to automate as many tasks as possible, so that I can spend more time on the more important tasks at hand and being more proactive.
Read more →

JavaScript MVC: Inheritance

If you’ve ever done a lot of JS development you might find the following situation familiar: you’re loath to open up the bowels of the sweet webapp you wrote because you know inside you will find hundreds of lines of jQuery selectors stacked on top of each other. Try as you might, they just won’t be tamed simply by separating out into distinct functions. Soon you’re lost in your own code, trapped in a Borgesian labyrinth of your own making.

That was one of the first challenges we ran into when I started working at Behance: the decentralized, deframework-ized nature of the client side code. Like many other shops, JavaScript was viewed with equal parts suspicion and distaste. But as our code grew, it became increasingly impossible to continue working the same way as thousands of lines of JS collided tectonically into each other as Everests grew out of merge conflicts.
Read more →

Developer’s Toolkit: Kevin Ran

This post is part of a series where Behance developers talk about the various tools they use to get things done and make ideas happen.

1. Who are you, and what do you do at Behance?

I’m Kevin and like a few others on the Dev team, SUNY Binghamton is my Alma Mater. Personally, I play guitar, [lots of] video games and animate things once in a while. I’m also an avid C/C++ programmer. Overall, a very simple guy (despite the C/C++ part).

At Behance I’m a full time QA Engineer. It’s been a lot of manual testing of new features, automated testing and maintaining the framework that we use for those tests – our page objects. I focus a lot on enforcing a clear, maintainable pattern in our page objects, not just for ease of use (by me, Dan and potentially other devs), but for extensibility. It’s thrilling because I get the unique opportunity to focus on how efficient my code is and how to utilize and combine language features in nifty ways!
Read more →