This article was originally posted on Medium.
ActiveState recently launched the first feature of our new SaaS Platform for open source languages: Python Runtime Security. We sat down with ActiveState Chief Technology Officer and VP of Engineering, Scott Robertson, to answer questions about the new Platform and how it addresses the challenges of developing with open source languages.
In part 3 of this 4-part series, Scott discusses the rationale and evolution towards Continuous Integration / Continuous Deployment. Follow the links to see other posts in this series:
Part 1: Platform Vision
Part 2: Solving SDLC Challenges
ActiveState: Let’s talk about CI / CD, why do companies implement it? What needs to be considered of CI / CD environments in the context of the challenges we’re solving?
Scott: We can unpack those acronyms. CI stands for Continuous Integration. It’s the concept that every time I make changes to the code I want to make sure I’m following all the best practices after making changes to the code. That includes making sure you run all your unit tests and making sure you’re reporting your stats and everything else to see what kind of code coverage you have.
It’s basically doing all the things you want to verify when you’re integrating code to ensure it is working. The new changes we’ve made — have they broken the old system? That’s why you go out and set up automated systems that are constantly checking for revision control, running a battery of tests and other processes and making sure everything works.
Continuous Deployment is an extension of Continuous Integration in that once everything has passed integration test suites and everything looks good we can deploy to production. That’s really the heart of being an agile organization. I can make many changes as rapidly as possible without quality suffering across the board. In traditional software development we had release cycles that were anything from months to quarters to years. And now we’ve moved to a world where most organizations have bought in and see the value of making many changes in a given day.
As soon as we know a feature is going to add value and it’s not going to break anything else, we want to get it into our users’ hands as quickly as possible. And it could even be just fixing bugs. So that’s the whole reason we want to set up these systems — so I can address problems or add new value instantly without being behind some sort of arcane, manual-based workflow to make sure that quality hasn’t suffered.
More to Come
Stay tuned for Part 4 of our Q&A series. Scott identifies unique challenges to working with open source languages and how the new SaaS Platform is positioned to address them. See you next time!
Interested in trying out Beta functionality? Create a free account on our new SaaS Platform for open source languages.
