By Marleen Linares
January 8, 2014
uShip’s VP of Engineering Nick Parker’s top priority is the lifestyle and happiness of his developers. That’s why he and his team are one of a few companies using a process called continuous deployment.
Instead of pushing code into production every two weeks, like most companies, uShip’s development team pushes code about every two hours. As soon as a developer has finished perfecting a piece of code, he or she can push automatically put it into production. In minutes, the developer will receive feedback.
If uShip followed the more common deployment schedule, every other Sunday Parker’s team of top developers would deploy the code from the last two weeks into production. The developers would stay up through the night, modifying or eliminating code that was not working for various reasons. The team would get little to no sleep Sunday night only to spend all week catching up on the lost sleep.
“It’s terrible to have your highest paid people-the ones you want to retain the most-have to work through the night every two weeks,” he said.
“I want my developers to love their job. I don’t want them to hate every other Sunday.”
Some of the uShip team
As the world’s largest online shipping marketplace, uShip allows consumers and businesses to compare and book shipping quotes, name their own price or receive auction-style bids from over 225,000 customer-reviewed Transportation Service Providers. These providers range from independently owned operators to large freight carriers and brokers.
This high traffic calls for a high functioning engineering team. uShip’s engineers are constantly improving the platform to achieve their goal of simplifying the shipping process. These fixes can range from improving how objects to be shipped are listed on the site to simplifying the bidding process.
uShip is one of the few companies that is almost constantly pushing code into production. Although Parker and his team used to push code once a week, he realized it wasn’t an efficient way to develop.
“It’s time consuming and it’s really expensive [to push code less frequently]. A lot of companies end up stuck with these bugs that they’re scrambling to fix,” he said, noting his friend’s company pushed code quarterly and spent a month trying to find a bug that was causing their site to load slowly.
“If there is a bug, we know where it is and when it happened exactly. It’s a teeny bit of code we have to fix rather than looking through thousands of lines.”
Dean Jutilla, the Senior Director of Marketing Communications, said the process also makes the business run smoothly.
“They push some code that might reflect the test from that and Nick comes back and says ‘hey guys what you theorized is correct or completely off,’” he said. “We didn’t spend days or weeks or months waiting to see if it would work. It makes the business cycle move.”
A bit of uShip’s office
According to Parker, the process is not easy; uShip hired a full-time engineer just to run the deployment process. However, many companies are hesitant to use continuous deployment because of the perceived risk factor.
“It seems like it would be very risky to push code so often,” Parker said. “There’s actually less of a risk with this system.”
The risks are low because of the automated health check system the code goes through, after it passes human quality assurance checks. After the code passes those tests, it is rolled out to 10 percent of the users. Once it passes all of the health checks, the code is rolled out to the rest of the users.
“We still do the same amount of tests and quality assurance checks,” he said. “When you’re pushing code that frequently, the risk is tiny comparatively.”
Parker has been with uShip since the company was founded in 2005 and built the site from the ground up to the more than 60 developers today. However, they have been using continuous deployment for about three years now. The biggest challenge has been encouraging the developers to be confident enough to push their code frequently.
“If they’re apprehensive about it, there are problems whenever they do push code,” he said. “Invariably when we see codes that have been sat on, it leads to issues.”
Giving the developers confidence in their code is a priority for Parker.
“We’re making a culture where engineers feel empowered and feel their code is constantly making a difference,” he said. “They can see that right away.”
Although Parker stands by that continuous deployment makes sense from a technological standpoint, it also resonates with his company standards.
