Okay. We’ve analysed the problem, we’ve produced an excellent design, and we’ve got our security approach nailed down. It’s time to get our hands dirty and actually build it.
With a good design in place, one might assume that development is a simple task. You just go away and do what it says. But for File Guard, we decided to do things a little differently.
Rather than a “big bang” approach, we decided to target end-to-end functionality in the development of File Guard. First we’d get data going in and out, then we’d get guarding taking place, then we’d get quarantine of bad data happening, and so on. That way, we are constantly validating that all the pieces fit together. Not only that, we constantly have something we can visibly demonstrate to anyone interested. And as engineers, we get to see our creation actually operating very quickly, so we get to feel a bit warm and fuzzy inside.
Sounds sensible, right? And, it is. But this subtle change in approach has various implications to be considered.
The main implication of this is that we need the capability to not just test a particular executable or library, but an entire appliance. We need to be able to whip up such an environment quickly and easily, and we need the capability to keep it current with the latest updates.
Assuming the code is already done, we need to be able to go from zero, to RHEL server, to files going in and out and to guarding those files, in record time. We also need to ensure that each engineer’s environment is in the same state, and also that our code updates don’t interfere with each other and break things.
Thankfully, we know appliances, and we know RHEL. So our processes enable us to get a Virtual Machine running RHEL with our software installed fairly easily. And we also know how to set up a package repository so that getting the latest updates to our code is as easy as typing “yum update”. All we need to do is manage it all.
So we did two things. First, we agreed on the process. When you write a new feature in, you test it, then you build it into an RPM, add it to the package repository and tell people you’ve done it. Second, we agreed to communicate – constantly. We have short, daily stand-up meetings and Kanban boards so we all know what’s going on, all the time.
It takes a little bit of management, but the advantages are huge. Now, the environment in which we test our software is extremely close to the environment it will really be running in for customers. There’s no cries of “Broken? But it worked in my test environment…” There’s no “I think this will work, but it’s hard to test in this environment.” It works or it doesn’t, and getting the latest build into a proper environment to try it out in is quick and painless – because we invested the time beforehand to figure out a system that makes it so.
What’s more, we know our changes won’t interfere with each other. We tell each other when updates are available. Not ready for it? Don’t update that package yet. The update is there for you to pull down when – and only when – you’re ready for it.
Finally, if anyone wants to know what File Guard is, or how it’s progressing, we can show them – right there and then. We don’t need to prepare an environment. The whole team all have one, ready and waiting.
What would you like to see?
Disclaimer: This article is written by one member of a team, about a project that is still in progress. Knowledge may be imperfect, and things may change. This article intended to be nothing more than opinion, and should be taken as such.
Once Upon a Camayoc 