Ralph Krausse

I decided that it would be worth it to spend the time to bring in a SDLC.

Source Code Management

We were using TortoiseSVN and well who doesn't love a centralized source control system? It's slow, painful and not very team friendly. So…. I guess me, I don't. I brought in GIT, installed GOGS, a freeware self-hosted git service, and installed Jenkins. I was able to convert projects that I used often to build automatically using MSBuild and MSDeploy. So now at the click of a button, I am able to build one or more projects and deploy them to test or production.

Kanban

We are using Assembla for bug tracking. It was Kanban 'like' so we started using that to start moving in the Agile direction.

Azure/DevOps

We were still missing parts, so to complete it, I suggested to our CIO we replace our VMWare environment with Azure on Prem. We were using some Azure in the cloud but it did not make sense to me that we have a completely different environment on prem. Then we replace Assembla with Microsoft DevOps and bring that on prem. This way we can have full control, in an organic environment. We would have projects define in DevOps where would could have a wiki with a project explanation, server information, configuration information, etc – basically a central place where we can keep all the information about the project, your one source of truth. Then DevOps has a great Kanban board that is integrated with other parts of the system. We use the repo DevOps provides to replace Gogs. Use Azure pipelines to replace Jenkins so we do not have to manage that. Add unit and system testing using DevOps. Allow for pull requests when we have code changes. And allow someone other than a developer to deploy a release to production so that the engineers do not have access to production, which is a common request. The next steps are to migration to .NET Core from .NET for many reasons but one main one is that it integrates better with DevOps. Also I wanted to, for cost reasons, deploy our WebAPI to Linux instead of Windows and lastly, move this ALL to Docker containers.

CI/CD

Doing most of that gives us a usable, showable and standard way to do CI/CD.

MSI's internal applications (still) run off of mainly one, monolithic webform application. Seeing that future development had to change, I proposed an ecosystem of microservices (before that phrase was coined) and full APIS. To support this, I create an environment to do that so that greenfield projects could be loosely connected.

The host is a service based class that dynamically load DLLs based on meta data. In development/debug mode, it is loaded via a simple windows application so it can easily be attached to the processes while in VS IDE. In test, staging and production environments, it is loaded from a window service so that it automatically runs when the machine is rebooted and runs quietly in the background.

Once loaded, it reads in a json file and enumerates the services (DLLs) to be loaded. To simplify the process, with each DLL, it creates an AppDomain, loads the target with Assembly.LoadFrom(), then using reflection, reads the exported types to ensure the DLL was written with specific interfaces. Once confirmed, find the initialization method in the loaded DLL and invoke it.

Each DLL is responsible to do it's own work but all have a required container that inherits from TaskContainerBase which exports

This allows the TaskService to validate the DLL and can invoke Start() or End() on it so that it can be independently developed, and only knows how to run it or stop it.

After the DLLs are loaded, it monitors the configuration file, more specifiable an enable flag (true/false). If set to false, it will unload the DLL (allowed because it is in loaded into that AppDomain) and will load any new DLLs. This allows me to load and unload any combination of DLLs at runtime without effect other running DLLs. I did not want to be forced to stop the entire service just to upgrade one DLL for instance.

This entire environment allowed us to scale horizontally. Assuming you needed more horse power, we could just add another service, configure the endpoint and lets other applications access it. It was a great solution to scaling vertically.

I ended up creating a few WCF and WebAPI services. Again, in the end, the service has no idea what the service does, it just knows how to load, start and stop it. It was up to the engineer to user the correct base class/interface, then write their own code. We ended with microservices like an email and a sms service, and more WebAPI that dealt with connecting an overseas immigration system to our own and a service that allowed for customized Excel Reporting.

This changed the mindset from a monolithic software development to a services/api development environment. One did not have know how to send a text, you just called an API now. One did not have know how to send an email, again, you just called an API now.

Earlier I mentioned that MSI main technology platform was WebForms. While I applaud Microsoft's attempt of bringing in C# developers in the web world (and it was pretty impressive), I failed to embrace it. So I first brought in AngularJS and I did like it. Then Angular2 was born. Ignoring all the love/hate talk out there, I adopted it. I figured that it would be supported for along time (I assume) since Google was pushing it. Also, and I will speak to it more later, but there is a company called Telerik that was bring out a way to write native mobile applications using Angular. So sold!

I was hired to bring in best practices and new technology so I did. I wrote MSI's public facing Visa Immigration application which was in Angular 5. I also wrote the back end to it using C# WebAPI's. It was to be in ½ in the cloud, ½ on prem.

For development, I was able to leverage the TaskServer (See WebAPI and Microservices Environment) to host the WebAPI bypassing IIS for performance reasons (it does still run under IIS on test/prod). The cloud side would house the Angular 5 application, 2 sets of WebAPIs. I used Entity Framework Identity for token based authentication. Another set of APIs would communicate with the OnPrem APIs since we needed to integrate with other services and data.

There was a need to change and update immigration destinations, fees, etc on the frontend. Instead of having me update the code with new data when needed, I created a Excel Spreadsheet that the Immigration team would fill out and then import using another application (another Angular 5 application) that then allowed them to preview the data and publish the data, which would make it available on Production. Even though updating the main application would have been easier, in the long run it was worth it to take the time to write an import application so that the Immigration team could manage destinations, content, fees, etc instead of me doing that work on their schedule.