Introduction

Legacy projects are hard to deal with. Unless you are directly involved with the development of the system, you do not have any idea how hard it is to maintain and worse change. Something that sounds easy, like adding a simple button on a single page could in actuality be a nightmare to accomplish. That single page could be generated in back-end code with some homegrown framework that spits out HTML as the user interface and it is actually used for every single page in the system. I like to say that the “Devil is in the details.” Without the details and firsthand experience with the specific system it is difficult to gauge the effort needed to accomplish a task. This is especially difficult on a legacy project.

 

You know need to modernize your project but the task is daunting. It makes your head hurt just thinking about it, you don’t know where to start, and you rather just keep working on getting that single page changed and hack in that button somehow. I’m going to define a Legacy Project for the purpose of this series of articles as a system that was written and deployed without any consideration for DevOps methods and practices.

 

I’m going to walk you through a scenario, except for this one actually happened, and it happened to me. I joined a small company as the only technical resource. The previous developer suddenly quit and the company was left with a custom credit card management enterprise application written in Java, but no one knew how to keep it going. There was a 2 to 3 month gap between the last IT Director/Developer and myself and there were issues piling up. For a time reference, this was in late of 2012.

 

My first day I was handed and external hard drive with my predecessors Windows laptop data and an Excel spreadsheet with host names and passwords. Oh and someone said, “Here’s where you sit and we are having some transaction settlement issues can you get on that?” Let the nightmare began I said to myself.

 

A coworker once said to me that I thrive in chaos. He was right, this was chaotic and I loved every minute of it. Let me describe what I was dealing with.

 

The Legacy System

There were four Java Based Web Applications, one of which had an Adobe Flex front-end. These were running on JBoss 4 (JBoss 7 was current at the time). A MySQL Database Cluster synced over an OpenVPN WAN connection. One database was in Denver Colorado the other was in South America (Don’t ask), with the other database driving a similar app to one in the US (but built for a different market). There were old hand-built servers acting as firewalls and an FTP server. The servers that were in Colorado where in a rack that was not being rented from the co-location facility directly but from a 3rd party that had extra space in the co-lo. Meaning if I had to do anything I had to call up this 3rd party, who put me on the list and then I could get in. If it was an emergency in the middle of the night, I had a problem, as I could not just show and do some work. I had to get pre-approval from another company.

 

The server in South America was worse, since it was just a desktop pc motherboard grade piece of hardware (no remote management). If that had a problem with it, then I had to email someone and have him or her try to reboot the box.

The development environment consisted of a CVS source code repository server that had the “right” bash/ant scripts to create war files for some of the apps. The other apps where built via the Windows Laptop and the IDE it was using, either NetBeans or Adobe Flash Builder, depending on the application. There were no unit tests. There was however some Java “Main” programs spread throughout the code to exercise pieces of the system that was being worked on at the time.

 

The app used a homegrown Inversion of Control like framework (this kind of did the same thing as what the Spring Framework can do) and a custom ORM framework built in house, which was named DAL-J. I deciphered this to mean Data Abstraction Layer for Java and it included a custom tool to read the real database schema and create objects for data access. I take my hat off to the folks that worked on that.

 

The Need for DevOps

Does this sound like your legacy project? This series of articles will detail how I did it. So to recap this is what I was dealing with.

• Multiple Legacy Systems
• Older Source Control (CVS)
• No Build Automation
• No or Minimal Test Automation
• No project management or bug tracker
• Out of date libraries, frameworks, and software
• Horrible data center situation, running on older and unsuitable hardware
• System was so overwhelming, that people are quitting.

 

This series of posts will be part case study and part technical how-to on my DevOps approach to do more with less (people that is).

 

In the next article we will explore the goals for the retrofit and the benefits of doing so.