The CI/CD and DevOps Blog

Avi Cavale

Avi Cavale
Find me on:

Recent Posts

REST API best practice: One Database call per Route

Shippable has been on a roll for the last 8 months. We scaled our team by 3X, had the best-ever release of our continuous integration and delivery platform on February 29, and we’ve continued launching 10+ features every month since then. 

As we scaled our development team, every new developer joined us with preconceived ideas about how software is developed. Unfortunately, software development is pretty inefficient at most places, and this is one of the main reasons we started Shippable. We at Shippable do things differently. We focus on shipping code faster and faster, and we hold some principles very close to our heart. 

One of our strongest beliefs is in pure REST APIs. This means we follow the cardinal rule: thou shalt not make multiple calls to DB objects from inside a single RESTable route. So when any new developer joins our team, his first question is : Why do we call our API from within our API?

Our journey to microservices: mono repo vs multiple repositories

Microservices are currently the hottest topic in software development. The concept is simple: Break down your application into smaller pieces that each perform a single business function and can be developed and deployed independently. These pieces, commonly called services, can then be assembled into an application using some flavor of service discovery like nginx or consul. The microservices approach is considered the architecture of choice for teams that want to build scalable platforms and efficiently and rapidly innovate on them. 

As infatuated as I am with this architecture, our journey to microservices was a long and winding road. It has finally led us to a version of the architecture that gives us the scalability and agility we require as a business. I want to share my thoughts, experiences, and lessons learned in a series of blogs around this topic so you may benefit from our experiences. Also, I would love to get your feedback or comments on our approach.

When you start moving to microservices, the first question before you write a single line of code is: How do you organize your codebase? Do you create a repository for each service, or do you create a single ‘mono repo’ for all services? The two approaches are illustrated below:

Moving Beyond CI with Automated Pipelines

This is an exciting time for Shippable as we release the next version of our pipeline. As a SaaS company we constantly release new features and functionality, but this release marks a major update to our platform and services based on customer feedback and the "state of the art" for developers. You can read about the new features and updates in this blog post. In this post I want to take some time and explain how we have arrived at this point, and how we move towards the future of modern application delivery.

Shippable service update

 

Over the last couple of days, our service has not been as stable as expected and I want to sincerely apologize for this. I understand that Shippable is very critical for your CI/CD workflow and any service interruption is extremely frustrating.

WE SCREWED UP.

We have fixed the problem now, our service stability has improved tremendously, and we will take every precaution to make sure it does not happen again in future. 

In the interest of full transparency, here is what happened.

Since July 2014, we at Shippable made a decision to move toward a micro services based architecture. To live the world of continuous delivery, we made small incremental changes to almost all pieces of our architecture. 

Dear Ping-Pong, thanks a million (or two)! Love, Shippable

[The original post appeared as a guest post by Avi Cavale on Geekwire]

It all started at last year’s GeekWire ping pong and anniversary bash.

I had just founded my company, Qhode (now called Shippable). We were building a geeky product, a continuous integration and deployment service targeted at software developers. Even though we were solving a real problem, I had no idea how to market it.

I asked myself: How will people even find out about us?