For those who missed it, I was part of a fun discussion earlier this week on Continuous Testing and Test Acceleration, hosted by Electric Cloud. Sam Fell over there does this regularly as part of their C9D9 or continuous discussion series.
Basically it’s a group of us sitting around chatting about various issues such as how to enough when you’ve got enough testing, or what is the best way to get started.
Flo is the CTO and co-founder at Codeship, a hosted continuous delivery service. He’s passionate about immutable infrastructure and helping teams build more productive processes. @flomotlik | flomotlik.meblog.codeship.com
Software engineer for ClassDojo, an Educational Technology start-up in San Francisco. Gregg is interested in open source software, APIs, craftsmanship and Continuous Delivery. @GreggCaines | caines.ca
Trevor is the Co-founder & chief scientist at @Logentries, log management & analytics made easy. Irish, software engineer. PhD, @UCDDublin alumnus. @trevparsons | blog.logentries.com/
DevOps is a movement that recognizes how tightly coupled development is to operations in modern applications. With shortened lifecycles and increasing amounts of software, the old boundary has broken down. DevOps is in some sense the sysadmin form of Agile, allowing teams to not only produce software faster, but get it deployed.
The goal is to no longer have developers throw software over the fence, which is normally followed by Ops throwing it right back because it doesn’t work. Instead the goals of Ops are embedded in the software testing and even requirements.
For DevOps to function properly, the entire release process has to be highly automated and deterministic. By deterministic, I mean that there are policy driven measurable metrics that determine the important questions surrounding application development. Namely, is the software ready? Does it have the required functionality? Will it function properly post-deployment? Is it Secure? All the things that frequently have squishy choices around them have to be controlled so they can operate in a repeatable fashion. For example, you may have a test coverage requirement of 80%, or a unit test pass percentage of 90%.
In that world, it may seem that static analysis isn’t an important topic, but it turns out it’s actually an enabling technology. You can and should use static analysis not just as a bug-finder, but to get at the root cause of software that is vulnerable to produce more robust applications.
Friday I’ll be giving a webinar for Parasoft that will talk more about the details of using static analysis and DevOps. It’s free and will be informative. Bring your questions, and I hope to see you there.