April 16, 2015 at 5:59 am
Guys,
looking for advice on how to tackle the issue of software development lifecycle.
I recently started working for a company that supplies a packaged software solution based on SQL server, but the application is written in Uniface - don't worry, I have never heard of it either :-). The application is made up of a number of discreet programs and is essentially a collection of single-page-apps. The application is supported by a number of reports and ETL jobs. These reports and ETL scripts are in turn supported by views and sprocs in the database that are not used by the core application.
We currently have several dozen installations which are spread across 3 different versions of Uniface, various installations of SQL from 2005 to 2014 - mainly 2008R2 all on-premise servers and different releases of our software including two different major versions and 5 point releases. Most sites also have some customisation which affects the application layer and the database objects.
Application development is done in house as it requires specialist toolsets, but reports and ETL jobs are written on-site so the supporting objects are not included in any software release and there is absolutely no version control - not even notes in the scripts to say what changed and when.
Currently running any sort of application update is a world of pain. We have a 'stable' database for the latest point release (but no source code control to identify changes from the previous point release) and when you run SQLCompare (the one concession to difference analysis) against the customer database you always end up with a number of database objects where the current object is not compatible with the stable version: Fields may have different data types or lengths, may be in a different order, there will be extra indexes and some fields will have been added that are not in the release. These differences will be different on each site. Views and stored procedures have the same problem which is exacerbated by the fact that there are several hundred cluttering up the database that are to support the reports.
The way upgrades work at the moment is that customers only take them when they absolutely have to because they are very expensive for us to deploy. We then run SQLcompare and take all the objects that are non contentious and run a deployment script, ask the customer to test the system in UAT and then incrementally fix everything that doesn't work. Customers inevitably don't do enough testing and won't do bits that only happen infrequently (e.g. stock taking) or that require interfacing into external systems (credit card charging)Then when they go live, lots of other things start to break.
I am trying to convince everyone that it would be better to take the hit up-front and get all the site specific stuff for a customer into the release database and recompile the software against that, then deploy all the changes in one direction only, not only to this customer but also to other customers who are on that point release (i.e. a build increment as there may not be any functional changes) This means that you can get all of the customers onto the same database release path which will make future releases sooooooooo much simpler because you know you will not have any breaking changes that are on site.
I am looking for good case studies where a company has had a similar problem of a fragmented code base and gone through the pain of merging all their branches. The lack of source code control for any aspect of the application is a separate headache.
Failing that, can I just have some sympathy :crying:
April 16, 2015 at 8:00 am
You absolutely have sympathy. That sounds extremely painful.
When attempting to deal with this sort of problem, and it's extremely common, I always recommend that you document the pain. Get written down exactly how much time each step takes, and how often you have to repeat steps or redo steps because of mistakes and problems, etc. And then turn that into money, "And here are the salaries of the people involved in this for a total cash outlay of..." Might get you fired. Or, the company will see the pain in numbers they understand.
However, when presenting a problem, don't present problems. Present solutions. Make sure that whatever issue you pick out to measure and report on, it's one that you know you have a solid fix for. And, that the fix can be done in an incremental fashion. You can't just say, "We have to change everything, GO! GO! GO!" because most company's will not allow it.
First pain point I'd focus on, source control. Show how if only you knew which changes were being made you would have avoided problem X and saved Y amount of money and the solution is Source Control. Build on it from there.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply