How A Progressive Software Development Studio Uses .NET
Application Development Code Reuse
Code reuse is one of the most talked about things in development circles. Unfortunately, a lot of developers like the idea of code reuse and are great at using existing open source libraries, but most don’t actually write code that is reusable. The reasons are wide and varied, but some of the common explanations (excuses) for writing one-off code are:
lack of knowledge
difficulty in planning out thoughtful programming
confidence to create clean, concise code
time to get this project done vs. saving time on the next projects
All of these reasons are legitimate, but with a little knowledge and some discipline, code reuse is easier than you think. Over the past ten years developers have built better tools to package and reuse code.
These tools combined with foresight allow all developers to build and reuse code.
So how do the software programmers at Skookum Digital works use Github, TeamCity, NuGet, and Visual Studio to build our module platform? Let’s examine our process and highlight some lessons learned.
Skookum uses Github for our source control system. Github is based off the wonderful source control product git. Github provides a lot of interesting features that make developing code, especially open source code, a pleasure.
The process starts off with identifying code that is reusable. This is where the knowledge barrier typically comes into play. It can be difficult to know when code is going to be reusable. A lot of different blogs have entire sections devoted to identifying the properties of reusable code based on languages and frameworks. Some great examples are:
Most modern languages though provide some concept of breaking code into reusable blocks. In .NET, we focus a lot on OO principles, SOLID principles, and—depending on the complexity—Domain Driven Design principles.
At SDW, each time we identify code that can be broken into a module, we create a new Github repository to store that code. This isn’t strictly necessary, but it just makes configuration easier.
NuGet is .NETs package management system and nuget.org provides an open platform to share modules across development teams. You can upload modules to nuget.org if you want to share with the world, or you can setup your own enterprise nuget.org server very easily.
Here at Skookum we are currently running our own NuGet server based off TeamCity. No special setup required—you setup TeamCity you automatically have access to a private NuGet server. We plan on releasing any open source modules on nuget.org, but we also have closed source modules for specific clients that we cannot release to everyone.
It is important to setup roles on TeamCity so that you keep these two worlds separate. Getting setup on nuget.org is really easy;just register an account and use the API key from within TeamCity.
We have seen TeamCity in part one of our .NET series and the power that it provides. As mentioned, TeamCity also supports a NuGet server out of the box.
We currently have our modules setup such that if TeamCity can build, run unit tests, and verify the modules have enough test coverage, they are automatically built into NuGet packages. These NuGet packages are then stored on a internal NuGet server. We additionally have TeamCity setup such that when it builds the NuGet packages it does so using Semantic Versioning. It is very important to version your modules and to follow specific guidelins so that other developers know when breaking changes, etc. are coming.
In Visual Studio, we just point to that NuGet server—and voila—we now have a system to maintain and update code modules. This makes it super easy to break out code and share it with other developers (and other projects as well). This is especially important to us as a custom development shop so that we do not rewrite the same code over and over again.
(In part three of our series you will read about a security module that we have built and successfully integrated into multiple projects.)
It’s simply a matter of right-clicking a solution, viewing the packages, and then choosing to update a particular module as necessary.
Here at Skookum, we have developed a system to encourage our .NET developers to think and build modules. Now when we recognize a module, we can quickly set it up for resuse in other projects (this takes about one hour to do the full setup).
We have made the code reuse process as automated as possible to ensure we are focusing on solving business technology problems and NOT focused on code infrastructure and deployment.
We look forward to continuing to leveraging this system and beginning to open source more of our .NET modules.