Practical Technology

About a year ago I started harping on the test automation bandwagon, and had introduced basic smoketests & New Relic Synthetics 'scripted browser' monitors (both Selenium-based).  In the spring of 2016 I used the Pluralsight course ' https://app.pluralsight.com/library/courses/automated-testing-framework-selenium ' to help build our inaugural UI test framework.  I wrote out a number of smoketests and 'hey this bit us on the last deploy, let's write a test for it', and the idea quickly proved itself.  Very shortly afterward we hired a QA guy specifically for automation experience, and now... He (Dan Lomanto) took the framework to a whole new level, and it's now the defacto way forward for QA More QA folk were hired, and they are now learning to use the framework to write mundane tests Some QA folk initially were 100% in the camp of 'QAs do not  write code, ever' - and now they are pushing themselves forward - learning not just our UI frame...

A lot of acronyms.  So we have a pile of IIS servers in EC2 and want to get the IIS logs into our ELK.  After much mental anguish I chose this method.  Why?  Because in our test environments you might have a bunch of IIS sites on one server, whereas in staging/production you'd only have one or two.  So having a bunch of filebeat.ymls kicking around seemed silly.  So this looks at your IIS config and dynamically creates the filebeat.yml based on those results! Here's the gist: https://gist.github.com/christrotter/143decafb217be355a93930be60d90d9 That script will generate your filebeat.yml with a prospector for each IIS site.  It adds an 'application_name' field ( part of our internal naming convention, set this to whatever ) with the site name (e.g. www.domain.com).  Ideally you'd have EC2 tags for all that, but hay.  Iteration1 and all that. It can also be run over and over (e.g. for testing config file changes); somewhat idempotent. ...