Back in the very beginning, Onshape was founded to provide a solution to problems engineers face daily, such as difficulty in collaborating, difficulty in determining which version of a design is the latest version, loss of control of design data, and pain of administering CAD seats. A lot of those challenges have nothing to do with the geometrical side of CAD. But we knew we needed to focus our attention on solving those problems.
In this post, I will focus on one particular strength of Onshape: continuous deployment. Continuous deployment is the ability to frequently push changes to the software to users, allowing for quick bug fixes and agile implementation of new functionality. Traditional file-based CAD releases new features/functionality once every year, or every six months maybe. It is hard to release new functionality more frequently because such changes often require a “schema change” and schema changes mean incompatibility and risk of regression.
With Onshape, our goal from the very beginning, was to put the data in the cloud to allow frequent updates (often delivered every three weeks) with no downtime, and to eliminate incompatibility between software versions by having everyone on the latest version. But how exactly do we do that?
Above, we have an example of an Onshape Document. It’s lovely, right? Unfortunately, one of our engineers made a change to the Onshape code that caused it to rebuild as this:
How does that even happen? It turned out to be an amusing bug to track down, and I’ll touch on it later. The important thing is that we knew about the issue and were able to fix it before we shipped the change to any of our customers. Let me explain how that is possible.
It’s all about strong, reliable versioning. When we started writing Onshape, we knew that we needed to preserve designs regardless of when they were created or what changes had been made. One engineer’s bug fix is another regression. Just because something is equally valid, it doesn’t mean that it’s OK to force that change on the user. We version our code paths and, thankfully, our technology partner Siemens provides mechanisms to control the behavior of newer releases of their kernels so that they emulate the behavior of earlier ones.
What this means is that older designs can use the code paths that they used when they were created and the results are the same as they were then. Newer designs get to use the newer (and hopefully better) code paths.
Only a really trustworthy or naive person would think that software engineers write zero un-versioned behavior changes – it’s just not a realistic expectation. So even with the best intentions, things are still going to break and that’s not good.
I remember in my past professional lives that we would often be dealing with regressions whenever we pushed a new version of our software. Why? Because there is just no way of ensuring that everything is the same when you don’t have all the customer data and can’t see over the wall between the R&D team and the customers. We would push new versions of the software and would effectively be keeping our fingers crossed that nothing too bad happened, based on as much testing as we could do. But we were effectively blind. How could we see every design? How could we ensure that we never broke anything? We couldn’t. Things inevitably broke.
However, Onshape is different. Our software has access to all Onshape Documents. Our employees cannot open or see private Documents, but our software can process the Documents and answer simple questions.
So here’s what we do. We have bots crawl over all the Documents and regenerate them on a newer version of Onshape, every three weeks. All the bots need to do is tell us whether any produce a different result and give us some idea of the type of differences, e.g. something has changed shape, or a feature status has changed.
If they DO find issues, then we have a problem. It’s not a big problem because no customer is affected (yet), but they would be if we pushed the changes to production. So now we need to take a look at the affected docs. I should stress again that this data could well be customer data that no one at Onshape can see, but all the bot does is tell us which docs have problems. So are we still flying blind if we can’t see it, like old file-based CAD companies are? Absolutely not. Free Onshape users and their public docs are great for this because we can get access to those as easily as anyone given that they are public. On the rare occasion that a bug is only visible on private docs, we ask the customer to share it with us and they almost always are happy to help.
Now let’s go back to that obscure bug pictured above. It’s a simplified version of a bug that was not found by our handcrafted automated tests. We ran the bots over our production docs and we got errors. We saw that the errors were all related to sketches and that there were public examples. Our engineers then examined the public Documents with both the new and old code and saw that sketch text was regressing. I will spare you the boring (yet rewarding) part of the bug hunt and cut to the end. We had made a change to the encoding of strings being transferred to the geometry server that messed up certain Unicode characters. Once we found the bug was fixed, we ran the tests again and the failures disappeared on the public AND private docs.
Over the last few years, these tests have found a number of bugs and we run them every three weeks over millions of Documents. You may think that’s crazy: How could we possibly do this? Well, it’s the cloud. We don’t have to wait for all the machines in some overheated server room to get done. I don’t have to ask someone in the ops team to pop down to Best Buy and fill a conference room with new machines whenever our customers make more Onshape Documents. We just pay Amazon Web Services to stand up new instances for the time they are needed, then we shut them all down when done and stop paying.
So to summarize, the cloud enables Onshape to deliver exceptional value. Not only does it allow secure storage of customer data, but it allows us to validate new algorithms and the elastic expansion means we have as much horsepower as we need to keep all that data healthy.
(Curious about how things in Onshape work “under the hood?” Let us know what you’re curious about either in the comments below or in the Onshape Forums and we may explore your topic in a future blog post.)