Ansible inventory management is generally very simple and intuitive, but there are some infrastructure configurations that are difficult to express and configure with the built-in inventory and configuration variable functionality. Specifically, it is difficult to configure lists of a certain resource type (like users) across machines that are in different but overlapping groups (like QA environments overlapping with datacenters).
These situations are certainly possible to manage in Ansible, but we at Leapfrog wrote an Ansible plugin that offers a different way of declaring variables that we think can sometimes be more clear. That plugin is available here:
When you are new to Scrum, it’s easy to focus on the concept of finishing everything you have committed to within an iteration. Because when the process instructs that you write user stories of manageable size and deliver small increments of functionality, it’s unsatisfying when the work is not done by the Sprint Review or the next Planning session, right? That is how we define carryover – work that was not done in the sprint but is still valuable, so the story needs to be carried into the next sprint for completion.
Let’s be honest. It’s not just people who are new to Scrum who feel this way. It’s veterans, too. Carryover tends to create uncertainty because it doesn’t seem to fit cleanly into the Scrum framework. But what we are learning is that carryover is as much a part of Scrum as the Daily Stand (if it weren’t, would it have ever received a name?). There are a number of reasons that carryover can happen, these are just a few we witness at Leapfrog:
All software has bugs. From Microsoft Office to joeschmoe.com. Bugs are a reality. And a major part of representing a product is being a first line of defense against “bugs.” If users are allowed to, they will go and tell a developer every time they think they’ve found a bug. That’s the fastest way to a resolution. If what has been found is indeed a bug, the fastest way to fix it is to have someone who writes code be aware of it and write code to fix it. And in a perfect world, where users were wildly competent at diagnosing a system, this behavior might be okay. But this is not a perfect world. And it isn’t fair to assume that someone who casually uses software is going to know the ins and outs of each piece of functionality. And if every user had access to developers, nothing would ever get done. So if it’s your responsibility to own a product, it’s your responsibility to be the first responder to “bugs.”
The first and most important thing to establish here, is you need users and...
Last week a few in the Leapfrog team attended the Anyone Can Learn To Code (ACLTC) showcase at 1871 Chicago. Our goals in attending the showcase were to: share with these graduates who Leapfrog is, increase the pool of candidates for Leapfrog engineering job openings, and get an early chance to talk to people as they transition to their software engineering careers. The ACLTC showcase was from 11am-1pm, during which we had the opportunity to converse with almost all the graduates. The conversations started with the graduates individually sharing a demo of their project at their tables, our team asking questions, and us sharing who Leapfrog is and what we do.
Demos from graduates were generally succinct and well communicated. The demo format allowed the audience to understand the purpose of the project, its functionality, and, in some instances, features that the graduates were planning on adding. The best demos gave us an insight into the graduates’ development process: the development...
After some failed attempts at propping up a satisfactory WSUS server to manage patching our Windows hosts, we finally achieved a non-right-clicky Windows Update solution using Ansible and Powershell. Like any marriage of Linux and Windows, it wasn’t without its frustrations. Thankfully we continue to make use of the painfully achieved scaffolding by ansible-izing tasks such as SQL Server ChatOps and Hyper-V VM pause and resume.
Ansible + Windows: much pain, great reward
A while back Ansible announced support for Windows and provided some example scripts to do things like install software and run Windows Updates. We were already using Ansible to script maintenance operations on our Linux servers so we were excited to use the same tool in our Windows environment. Unfortunately these example scripts did not fully work as advertised. Despite great documentation from Ansible and plenty of blogposts about Powershell and Windows Updates, we still spent a fair amount of time gluing all...