Getting Control of a Codebase
Getting Control of a Codebase
In this article, Simon Foster describes his experience of walking into a nightmare code scenario and cleaning up the mess.
Join the DZone community and get the full member experience.Join For Free
DevOps involves integrating development, testing, deployment and release cycles into a collaborative process. Learn more about the 4 steps to an effective DevSecOps infrastructure.
Recently, I started working on a new codebase. I will be honest; when I first saw it, it was a mess. Here are a few of the things I did to try and regain control.
I was given access to the source code on Visual Studio Team Services. However, this consisted of a single commit three months ago. When I looked at what was running on the production server, it was clear that changes were being made live with no regard for source control.
The first thing that I did was commit everything that was running live into source control.
Next, I created an SQL Server Data Tools (SSDT) project to keep track of all the database objects. Previously, there was a folder with some stored procedures in it, but these did not match with what was currently running.
I now had in source control the current state of the website and the database, so I knew that I could get things back to this state if I made some bad changes.
Let's start by looking at the website code I had. There was no solution file; the only way to look at the website was to set up my local IIS to run what was in the website folder. I could then use Visual Studio to open my local IIS website and attach to process to debug it.
This meant that the website was not going to do anything without a backup of the database running and that my SSDT project was going to be vital. However, the database was in a bad state; it consisted of a fair few broken objects and SSDT would not build.
Using find, I went through each of the broken database objects to find where in the code they were being used. Luckily, most were referenced in commented-out code, so I just removed all the broken database objects. The database could now be built. However, there was a dependency on the user table of another database. (This was the developer's solution to sharing logins between websites.) As I was using SSDT, I added a database dependency Problem solved! ...for now.
My solution was to use find and replace to replace all the $ with ‘ + CHAR(36) + ‘
So, I now have an SSDT project that builds and publishes but still no website project.
To get the website running from Visual Studio, I started off creating a .Net 4 website project and added Entity Framework 5 and MVC 3 via NuGet. I then copied all the website code into the new project, and with a bit of work, I got it to build. Most of the work was relating to namespaces and referencing the correct one and moving the EF model from AppCode to a custom named folder. A bit of trial and error later, I had a version of the website that could be run from Visual Studio.
I have not deployed my new version of the website as it needs further testing. No automated testing or even a smoke test checklist currently exist.
As my source code is hosted on Visual Studio Team Services (VSTS), I can get VSTS to build each commit and check I haven’t broken the build. This is not that helpful at the moment. Hopefully, one day I will have automated tests that can be run here as well.
Published at DZone with permission of Simon Foster , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.