One of the things I ran into a few years ago was the idea of a software pipeline. A set journey across machines and stages that your software takes. In modern, DevOps style development shops, this usually means:
- A development machine(s)
- A Version Control System (VCS)
- A CI/Build server/system
- An artifact repository
- Test server(s)/system(s)
- Production server(s)/system(s)
Usually software flows along this path as code is written, compiled, and moved from one stage to the next. You may have more or less stages in your environment.
For databases, this should be similar, with databases in
- development
- test/QA
- staging/pre-production
- production
You could also have other stages like integration, beta, user acceptance, etc. I’ve seen people with 7, 8, or 9 databases in their environment, all a part of their entire development and operational areas.
The database development pipeline is the set of databases that your code flows through. We’ve represented this with visually in DLM Dashboard as a flow, allowing up to 5 environments to be defined. You can see one of my pipelines in this image:
Keeping code flowing smoothly along this pipeline is the goal of any development effort. We know this at Redgate, and our mission is to build tools to help you do this efficiently.
Filed under: Blog Tagged: DLM, software development, syndicated 
