Interview: Continuous Integration and Deployment at GrabCAD

After our Continuous Deployment Meetup last May in Boston we talked a lot with Amos Benninga from GrabCAD about Development Workflows and the internal processes at his company. We were especially interested in how GrabCAD grew over time, how they practice Continuous Integration and Continuous Deployment and which technologies they use to cope with the daily challenges a fast growing company like his is facing.

We have been in touch ever since and a lot of valuable information has been accumulated throughout our ongoing conversations. Amos and us felt it would be a good thing to summarize our talks and publish them as an interview on the Codeship blog.

Name: Amos BeningaFrom: Israel, came to Boston 2002 for a startup.Working for: GrabCAD – Grab is revolutionizing the CAD industry.Why I started at GrabCAD: The business opportunity and technology was perfect for mePreviously worked for: BladeLogic, Akiban, Ekotrope

Programming Languages used at GrabCAD: Ruby, Java, Scala, Python, JavaScriptFrameworks used at GrabCAD: Rails, AngularJS, various librariesCloud Services used at GrabCAD: Amazon

Continuous Integration is testing your code all the time and keeping software quality high. It gives you the confidence to get stuff out as quickly and often as possible

Continuous Deployment is basically getting code into production. Things should be easy and repeatable. That’s where Continuous Deployment comes into play. Deployment should not be manual.

At my previous company BladeLogic. We automated the whole IT of our customers. Test automation is important. I don’t want to repeat many processes manually. It is definitely worth automating a lot of things. Things that would take long manually are very fast when automated so you should automate a lot. As a developer I want to be "lazy".

In the beginning we used Engine Yard for deployment. Over time we used more Scala and Java in our features. This was not supported as well as needed so we moved to AWS and put more emphasis on automation throughout the infrastructure.

We have about 30 production servers in place right now. You commit your code and if it passes all the tests it will make its way into production through our automated system.

We do Scrum with 1 week sprints. We do our sprint planning at the beginning of the sprint (which does not have to be aligned with the beginning of the week). Then the team starts to work on the features which have been agreed upon. Every feature that is done gets into production. The feature teams decide on their own how much needs to be tested for that feature. Sometimes we push to a staging environment.

When a feature is ready you merge to controller and then go to Jenkins and push the "OK DEPLOY" button. We release a couple of times a day.

After the week we do a sprint review.

Once a quarter we do release planning. The first week or two of the quarter is for planning the quarter and then we have about 8 to 9 weeks we can work on the features.

For the initial backlog we do rough estimations. We calculate in points. We look at points and see: “This team has about 600 points left and we know how much the team can still do.”

Goals come from the company level. The goals then get split up into tasks and features. We try to split them up in as small pieces as possible so we can get them into the sprints efficiently. We also do a semi-detailed breakdown with the aforementioned points (e.g. 200 points for this feature)

It’s not easy to define meaningful metrics for the engineering teams. Take this example:

A feature is ready and live. But then the marketing promotes it and everything else kicks in later. You can validate the result of the feature only later on. The engineering team’s goal is to deliver the feature.

Our KPIs for engineering are

• velocity (scrum points),

• number of deployments to production per week and

• number of regressions per feature/developer.

This gives us confidence in Continuous Deployment.

The sales team’s metrics include

• sales,

• virality,

• engagement and others

The development teams are pretty evenly spread throughout three countries. Having everyone in one place has less overhead in communication but due to circumstances we had to have three locations. However, having small teams has a lot of advantages and can compensate for geographical gaps. For example you can easily see where something went wrong and take quick action against any mishappenings.

We have teams in Estonia, the UK and in the USA. We moved away from very functional teams in different locations to cross-functional teams in all locations.

We do have specialized teams owning different sections of the product though. If everyone owns everything, no-one owns nothing.

We do shift our teams every so-often to keep them fresh or when we have a new project and see that a specific person is perfect for that task.

The core of the company started in Estonia and the CEO moved to Boston. Our biggest market is in the USA. Today we have the headquarters, the product management teams and the sales teams in the USA.

We were also able to land two key CAD experts in the UK which triggered opening the third location.

We now use JIRA and GreenHopper. Originally we used AgileZen.

They can commit to the work within the first week.

We want to make the staging and Continuous Deployment and Testing environment better. These things are massively important for development productivity. We are putting a lot of effort into it in this quarter.

We are also thinking about changing to different languages. In Rails some performance and maintenance tasks are not as we like them to be. We may change some things to Scala or Java to get better performance.

Currently we don’t do a lot of load testing. We might do it in the future. We use New Relic and our own monitoring. The GrabCAD website grew organically. We have a regular growth pattern now and its quite easy to estimate what’s going to happen in the near future.

We are on and want to stay with cloud providers. Cloud services are totally worth it. Think about IT people, servers, cooling systems and many more. There are a lot of hidden costs you save when you use cloud services.

We have some basic scripts. We are using Chef. Amazon instances provide a Chef client. It’s really easy to create the machines and it’s secure.

Getting something like this in place is work intensive and you have to figure out if it’s worth your time in the early days. We planned a lot of overhead to use Chef and built this setup.

We pay far less for our servers than for our office and salaries, so it's not an issue. If we want to cut costs we just have to improve our code base.

We want to thank Amos and GrabCAD for making this interview available to everyone. What are your thoughts on the processes and workflows at GrabCAD? How do you plan your tasks and which technologies are you using?

Let us know in the comments!

PS: Should you be interested in a convenient CI and CD solution, try Codeship.