Today we're featuring a story shared by one of our users, Ed Laczynski, CEO of Zype. Ed shares how Continuous Integration with Codeship has helped his team working more efficiently when producing features for Zype users.
One of my favorite Saturday Night Live skits is The Glengarry Christmas, with Alec Baldwin as the Glengarry Glenn Ross-inspired sales ace, brought in to motivate a bunch of rag tag elves to produce more toys for Christmas.
Now, we don’t live in a world where we can crack our whips at our developers quite like Alec Baldwin’s controller Elf did. I’ve seen (and have worked in) many boiler room development operations where production and quality of life lead to early staff exits and little results. As startup CEOs and engineering leaders, we need to give our developers the tools – the “Glengarry Tools” – to make them effective, help them manage their time, and ultimately produce quality products.
That is why we love Codeship so much.
The best tools “melt away” when you are working with them. Does the toymaker or carpenter have to constantly tweak, configure, and otherwise think about his hammer or awl? No. It just works. Sure, it may take some training (and Codeship did require us to stop some development operations to make sure we were integrated and trained correctly), but a great tool just works once you get the hang of it.
At Zype, we are constantly asked to deliver new features across a wide spectrum of video platform related demands – everything from video aggregation from platforms like YouTube, Hulu, and Vimeo, to managing advertising and subscription revenue partners. We need to be able to deliver our software quickly, every day, with robust testing that we know will ensure quality customer experience. We use a bevy of tools, from GitHub, to CodeClimate, HipChat, AWS, you name it. No matter what we use, Codeship makes sure that we are continuously delivering great software everyday.
How We Got Started With Codeship
When we first started using Codeship, Codeship helped us identify weak tests that were in our code base. For example, we have a method that queries a collection of videos where you pass in parameters into the method to scope your query.
In our existing test, we passed in three videos and expected that two of the three videos would be returned if we ask for only active videos in our parameters. Tests passed locally, worked great in staging, but when we pushed to Codeship, this test would fail about 20% of the time. This forced the team take a step back and look at why the test would fail every now and then on Codeship. Looking at the test we realized that the two videos did not always come back in the same order. We fix this order dependency so that our tests pass 100% of the time on Codeship, and have overall better code for that query.
Here just some of the ways we have learned to cobble better with CodeShip:
Codeship acts like a mini supervisor for small teams and maximizes the amount of time spent developing. When integrated with tools like Slack or HipChat, you have instant access to build status.
Codeship helps alleviate the overhead of managing staging deployments. Using continuous integration, we have the latest build of our application available to test at all times.
Codeship helps to prioritize team wide testing. If you push code that makes tests fail, you and your team immediately knows about it.
Codeship forces us to write better tests, knowing that your teammates may have to take on the burden of updating your tests to push their code.
We are really proud to have CodeShip in our toolbox. Happy cobbling!