The Problem
I've recently started working for a new company that operates in the insurance sector. They are an Oracle outfit with a few other technologies thrown in for good measure - there's even a mainframe. JOY!
Anyway, it quickly became apparent that they didn't truly understand their estate and they were looking at everything as a single system. As a build manager this set all kinds of alarm bells ringing - I hope they're not expecting me to build this huge system everytime there's a change to one small section...
Release day is worse!! Their current approach is to collate all of the changes for each of the subsystems and deploy them in one go and call it release X. Really?? Think about that in terms of Microsoft Office - I've made changes to Word and Excel, but not PowerPoint and then said we have version 2 of MS Office. We're then losing valuable information about the structure of Office; Word V2, Excel V2 and PowerPoint V1. I know its a crude example, but I hope you see my problem.
The Solution
Well, the first thing is going to be define solid boundaries in the system. Whilst this sounds quite straight forward, there's heavy dependancies on one of the systems in particular. Think of it as a viewer on a central database that is fed information from the other systems. Most often when a change is made, this 1 system will need an update too.
Implement a build framework. Currently, individual files are copied to a staging area then copied into the environments manually - this is not acceptable.
0 comments:
Post a Comment