As Information Technology departments in small to mid-sized organizations mature, they incorporate more of the processes and constraints previously seen. This is mainly in large companies including a change control mechanism that attempts to manage changes to the infrastructure on which the company is so dependent. This is a necessary move to ensure that systems are stable and reliable in an increasingly complex environment. The problem is that it also introduces a not insignificant workload and often leads to delays that can, if not managed properly, drastically reduce the productivity of development initiatives designed to improve those systems.
There is a temptation to treat all systems as production level and quite often development environments, particularly databases, are subject to strict change control rules and even sometimes the same rules as the production systems that they are being developed to update. Small and mid-sized companies cannot afford the staffing levels required to keep them agile in these situations. This can cause major delays when development work requires a database refresh to fix a problem or to test out the deployment of new code. To complicate things further, many of the actors involved now work remotely. Often entire teams are all remote, working from home communicating via email and chat applications. In and of itself this decentralized working should not be a problem but when it is combined with the ever-increasing push to do more with less and the inevitable increase in individual workload for the engineers involved, we are seeing more and more situations where things that should take an hour or less are taking several days to get done. It is no longer possible to simply walk over to a manager’s office and get something done. Often it requires booking a conference call appointment on multiple resources, calendars to discuss what is required, and then trying to get the request scheduled into the relevant engineer's busy workload.
By using some of the new tools at our disposal we can make provisioning of test and development systems much more automated whilst still conforming to sensible rules and providing adequate traceability and auditing. A developer can trigger the restoration of a development database or the rebuild of a test server on request without requiring any other human effort at all.
The first step is to properly segregate the production, test and development systems and apply sensible rules to each environment. It is still very much the case that a developer or implementation consultant for an application that has a database at its core HAS to know enough about the database itself to be able to determine when and how it should be maintained in a development environment. Without that knowledge, how are they going to create an adequate application that will perform with any level of satisfaction in the production environment? This means that we should not be reliant on the production database management staff to manage the development database and should be able to give much more control to the developer to manage their environment.
If we provide tools to perform provisioning and maintenance of the development environment in an automated way the developer can perform all the necessary functions on their own by triggering the automation on demand and be very much more productive.