I’m just a solution provider out here with what might be just a personal problem, rather than a professional problem. So what’s the problem? I CAN EXPLAIN. Now I hope you ask, WHAT IS TEST DRIVEN DEVOPS?
Test-Driven DevOps makes you not feel sorry for testers and quality assurers in the world of DevOps. This is because the tester can take a more leading role in the design process. Ultimately those who take down requirements and form a design pattern are leading on design, but I have seen quite a few startups putting the developer in a team of “product developers.” Now I ask them to start a more behaviour-driven (shared tools, shared process, shared development responsibilities) or domain-driven development (connecting implementation to evolving models.) process based on test-driven development which will inevitably fail in the first iteration. Once the test is written, a spec is formed. Let’s take a look at rspec for example. Here is some code which I copied from http://rubydoc.info/gems/rspec-core/frames
# in spec/calculator_spec.rb
describe Calculator do
describe '#add' do
it 'returns the sum of its arguments' do
expect(Calculator.new.add(1, 2)).to eq(3)
When you gem install rspec and run the test, it shall fail in that first iteration.
$ rspec spec/calculator_spec.rb
./spec/calculator_spec.rb:1: uninitialized constant Calculator
The simplest solution:A simple class adds a + b
# in lib/calculator.rb
a + b
Add this to the top of the calculator_spec.rb
# in spec/calculator_spec.rb
# - RSpec adds ./lib to the $LOAD_PATH
Some of you are probably thinking, “So what you can copy and paste an rspec example from the manual.” Sure, anyone can do that. But now thanks to a domain specific language aimed at solving problems of scalability, repeatability, and interoperability.. you can turn what would ordinarily be a PaaS of service-oriented architecture known as @GitStrapped into a multi-PaaS multi-class and roll forward from there, in a DevOpsy fashion. Time for DevOps multi-classing.
From a more operational perspective, as an early-stager in the early days of the commercial Internet, I learned the hard way that change is inevitable. With nothing constant but change, it makes a lot of sense to make changes more manageable by recognizing the inevitability of development in sustainable operations. What operator doesn’t test?
Test Driven DevOps isn’t just a fancier way of differentiating myself from the DevOps fakes, Test Driven DevOps is also a way of articulating the need for operational intelligence to include test results. If you don’t know how to accurately manage the resources it could be that you don’t know how to accurately measure results or costs in some cases. This doesn’t mean you suck, necessarily. It could mean that you have ventured into uncharted waters and now you want to see if you can get a horse to drink.
Once test results from the production environment form a cohesive summary of insights, an operations manager can begin to dish out a new set of service level agreements to audiences where he or she is raising the bar for what system quality means.
If the operator is an IT operator, he or she can use this Test Driven DevOps approach to reduce costs in his or her organization. If he or she manages an old enough shop, chances are they were already doing it and didn’t know how to explain it the way I do with tomorrow’s pre-freshness. Think about that the next time you configure, make, make install. When I toss an apple it might taste like it ain’t ripe, but if you can digest it, then you find out what kind of stomach you have for the tree that apple didn’t fall far from.
Money might not grow on trees, but I’m here to tell you that code really does almost always grow on a tree of some kind. Now you still have to water it… and developers drink beer that’s not necessarily the same PBR you can feed to the rest of our hipster community. You can lead a horse to water, but if it’s dead don’t kick it and expect to get any code flourishment from the kick itself.
The process of test driven devops empowers an operations manager or engineer and generally anyone in operations.. because the process makes the changer think about the impact of the next change in every iteration. It’s not rocket science, but how much you wanna bet I bet they use this technique before a safe launch?
The other thing even the most achieving highly profiled young developer could get out of doing Test Driven DevOps for real is all those insights into things you couldn’t learn within the constraints of confidentiality or half-published information out there.. plus learning the things that maybe you can’t so easily learn in school. In fact you also learn the things you cannot possibly learn in even the finest schools with the strictest regiment of competitive academics in their cirriculum.. because the damn things you’re discovering in this damn test driven process are the damn things no one has discovered damn yet, damnit! If that’s not dangerous, then not testing probably is. So there could be a decision about what kind of danger you decide to present these domains as alternatives. My opinion is to build trust and do Test Driven DevOps unless you have a reason not to. That will minimize the risks to all domains, I’m guessing, but if you need a guarantee I know where to find one and how to make them.. after working at Elastic Provisioner and delivering the Elastic Promise since 2010 or 2011 around that time. For those of you who haven’t heard, the Elastic Promise scales on demand because the client can sponsor the guarantee via TDD (following a thorough analysis of business objectives and of course requirements).
Besides if you’re not doing DevOps, why not?
Someone who favors predictions won’t allow you to see what happens when the experiment is complete?
— mhrast (@MHrast) March 8, 2013
— Julien Pivotto (@roidelapluie) March 8, 2013
Autonomous DevOps at Scale and Software Defined Networking
After the privilege of attending the Open-Network Summit (which is a conference discussing open-standards around Software Defined Networking… in case you thought it was a bunch of LinkedIn Open Networkers) I heard Vint Cerf briefly discuss the concept of permissionless innovation. Software defined networking can be a strong enabler of permissionless innovation for DevOps, because it exposes the dynamic network capabilities via REST or other APIs. When I think of DevOps at Scale, I think of permissionless innovation as a culture which networks across domains and that’s rather disruptive to systemic monolithia.
“How long does it take to do #DevOps.”
— (415) – Asher Bond (@AsherBond) March 7, 2013
A lot longer than you might think in that first iteration.
Shunichiro Tejima, NEC was asked during Questions and Answers what was the hardest part of implementing Software Defined Networking. The answer was the first iteration. Once you get past it, further development, implementation and innovation start to move with much more velocity. It’s because you repeat success from a coded template rather than trying to remember what was done before, what worked and what didn’t.
Enterprise is already somewhat familiar with the concept of a service-catalog. I use this to keep track of capabilities and they can be called by a developer’s native tongue.