One of the challenges we face working on deltaTools is that it blows up the whole concept of an environment.
Transcript
Hi folks! It’s Jason from Continuus Technologies.
As you probably know by now, we support the Enterprise Data Foundation, which produces deltaTools, the open-source DevOps toolkit for Data Management. In fact, because we use deltaTools with our own clients, we are also deeply involved in the development of deltaTools. So we spend a lot of time thinking about DevOps.
One of the challenges we face working on deltaTools is that it blows up the whole concept of an environment. Just to review…
What we typically call an environment in Data Management is a complex beast. It typically includes one or more databases, file drop locations both inbound and outbound, and message queues, as well as one or more app servers to drive the process and version control to keep things organized.
That’s a typical data management development environment. And, of course we’re probably iterating with deltaTest so we can deploy the highest-quality code possible. So where would we deploy it?
To OTHER environments, of course! Each environment in this STACK of environments expresses a somewhat older version–but a better-tested one–of your code base than the one below it. We use deltaDeploy in combination with open-source build tools like Jenkins in order to move code up the stack, and deltaTest to validate deployments once they land in higher environments. But for a typical institution, that’s it: just one stack of environments. So you don’t really need to think about it…
… UNLESS you are writing tools that operate across an entire environment STACK, as each member of the deltaTools toolkit does. In that case, you’re going to need an entire stack of environments as your development… what? Well, let’s call it a Stack. And then if you’d like to set up a persistent demo of your process—or if you’d like to deploy it to a client site—then you’ll create another environment stack in the target location.
And of course we use deltaRefresh to instantiate the components of the target stack, and deltaDeploy to manage the process.
And there you go! A whole new layer of abstraction beyond what you’ll see just about anyplace else.
So if you’re a developer, I have to ask… is this your jam?
Then please consider getting involved! EDF is actively seeking Data Management developers who would be willing to contribute some time to the deltaTools development effort. And I’m not talking nights and weekends: many institutions are perfectly happy to allow part-time work on open-source projects that address that institution’s requirements. So make the argument for deltaTools to your employer and see what happens!
Maybe you are an individual developer looking to broaden your portfolio. Maybe you represent an institution looking for an economical way to solve the DevOps problems that plague the whole Data Management industry. Either way, we’d love to hear from you! To get the conversation rolling, just drop us a note.
That’s it for now, and best of luck on your projects!