Hi Michael, Thanks for sharing your perspective! This is great food for thought. Your passion for the topic oozes out of every sentence. It's inspiring.
I have to take great issue with this assertion: > ...When configuration exists in two > places, the maintaince costs double. I have not found this to be true. Much like I have not found pair programming to double my feature development costs. It's an intuitive hypothesis, but not backed up by experiment after experiment after experiment. The double entry principle has saved my teams countless hours and problems. It is one factor in a series of principles related to Continuous Delivery that make complex systems easier to develop and maintain for years, by ever changing teams of people. I would be conservative in saying that well factored testing cuts the total cost of ownership in half, rather than doubling it. > The checks you insert using get_url and wait_for and assert/stat, etc, can > be part of the main playbook. > > Again the point is - don't make Ansible harder than it needs to be, a lot of > the purpose of it is to allow you to quickly move on to other tasks. I love this facet of Ansible. I love that mindset. Thank you, thank you. I think it has served the DevOps landscape very well. > One of the pitfalls of "infrastructure is code" is it brought software > development levels of complexity with it to infrastructure, when it should > have > brought only the idea of source control. > > This is what we're trying to change here :) We clearly disagree on this point. Version control was the least of our worries, and we had it in many places before the notion of "infrastructure as code" ever came along. And certainly before Chef, Puppet or Ansible entered the picture. (As an example: People have done amazing things with version controlled Make for decades.) I strongly believe that we have gained much by applying the notion that configuring infrastructure is something that can be compiled once, tested throughout and run repeatably in many places, with a single button click/command. Ansible has done great things for the ops world. Ansible has been very well received by even the stodgiest of old school sys admins. But, I sincerely hope that Ansible's message does not become one that undoes the notions of testability, formality, and communication required to build complex systems, repeatably, reliably, consistently, maintainably, and easily that have been introduced in the last decade. I'll now circle back to an earlier comment that you made: > That's the important thing I'm trying to combat - the feeling that it's *not > easy* and you need all this extra stuff. > For those people that like it, great - I don't want them to stop doing that > if that works for them for sure. I can get on board with this type of thinking. What I am doing works really well for me. It works really well for the teams I have been on. It even works really well for teams I have advised from afar. But, like anything, it will certainly NOT work well for everyone. I am happy to accept that. I do feel compelled to give the enterprise sys ops folks something that I think will be sustainable. And doing things essentially the same way, except version controlled with an idempotent fail-fast tool, won't keep them employed at companies that have to innovate quickly enough to keep pace with their competitors. They must fundamentally change the way they interact with their product teams. All that said, I love Ansible as a tool. The Ansible team has done an amazing job making it a great framework! Your documentation is clean and understandable. You've helped open up DevOps to a segment that was too scared of the heavier weight alternatives. Keep up the good work! - PJ On Thu, Sep 25, 2014 at 8:01 AM, Michael DeHaan <[email protected]> wrote: > > > On Thu, Sep 25, 2014 at 12:50 AM, Paul Julius <[email protected]> wrote: >> >> Hi Michael, >> >> Thanks for the response. Some excellent points. I'll respond to a couple. >> >> > As such, I strongly favor integration tests run against stage >> > environments to make sure >> > things work, and coupling that in a rolling update against a production >> > environment as >> > a condition to decide whether to add something back to a load balanced >> > environment >> > there as well - ideally using the same tests, but that's not always >> > possible. >> >> Agreed! Me too. I didn't address the downstream deployment stages, but >> this would be consistent with my approach. >> >> >> > While more of a unit test thing, I personally find Cucumber to be wasted >> > effort because >> > most product-management types (I guess I qualify) are not going to be >> > the ones writing >> > test stubs, so it's usually fine to just go straight to tests. >> >> Understood. On the contrary, I have found the type of tests I write >> when using a natural language approach to be a great mechanism for >> communicating requirements within a team. Though I wasn't sure, it >> read like you are thinking of Cucumber as a unit testing framework. I >> never think of Cucumber as a "unit" testing framework. > > > I guess what I'm trying to say is it's a language of defining "these are my > tests", "someone go implement these". > > I would agree it's not specifically unit test driven, but I guess it's more > of the statement > that it doesn't provide a lot of value to me over well named functions and > comments in the test > file. > > Stubbed out test functions would do the same thing. > > > A lot of users in ops land are new to development testing systems, so I want > to make it clear this isn't required, and there's not a big > gap that says you must incorporate 4 or 5 extra tools to use something as > basic as Ansible in most cases. > > That's the important thing I'm trying to combat - the feeling that it's *not > easy* and you need all this extra stuff. > > For those people that like it, great - I don't want them to stop doing that > if that works for them for sure. > >> >> >> In any case, my point isn't about Cucumber in general, but rather >> about the good practice of creating an acceptance test for a body of >> work about to be embarked upon. I am glad for teams to use whatever >> tool they think makes the most sense for their combination of team >> members and customers. By acceptance test, I simply mean an automated >> verification that the features we want actually do exist in the system >> that a customer and engineer can collaborate on. >> >> >> > Good integration tests for ops are more important -- is this web service >> > responsive? >> >> Agreed. >> >> > Not things like "is the file permission of this file the same thing it >> > is listed in the configuration >> > system - as that just duplicates configuration in two places. >> >> Duplication is precisely the point, sort of. I like Uncle Bob's point >> about unit testing being the double entry accounting of software >> engineering. We express the functionality we want in two ways: code >> and test. Then we automatically make sure our column sum equals our >> row sum. > > > This part I strongly disagree with. When configuration exists in two > places, the maintaince costs double. > > A colleague raised a very good point WRT ServerSpec in that in many cases > Puppet needs double checking more because > it can fail and only partially evaluate a DAG, but Ansible will fail-first > and make you fix a problem before proceeding. > > If it can't chmod something to a value, it will yell at you, and so forth. > > The checks you insert using get_url and wait_for and assert/stat, etc, can > be part of the main playbook. > > Again the point is - don't make Ansible harder than it needs to be, a lot of > the purpose of it is to allow you to quickly move on to other tasks. > > One of the pitfalls of "infrastructure is code" is it brought software > development levels of complexity with it to infrastructure, when it should > have > brought only the idea of source control. > > This is what we're trying to change here :) > > Hope that makes sense! > > > > -- > You received this message because you are subscribed to the Google Groups > "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgwaYmFdVBjdNucOStSBO6ornzzcAAy6FEdj%2BxgTDLqQsA%40mail.gmail.com. > > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BXRcNV%3DaUTPNobw0KR_VuzdCjhTPy68%2BAoDahbGEE53JmgT4g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
