How A Progressive Software Development Studio Uses .NET
.NET kinda/sorta gets a bad wrap in the open source development world. That's unfortunate because most estimates show two-thirds or more of Fortune 5000 businesses use .NET for some part of their infrastructure.
SDW prides itself on mixing the open source with the enterprise. It's advantageous for progressive, open source, and experimental software builders to have the knowledge necessary to sew organizational change from the inside out.
The following is part one of a three part series describing our .NET application development infrastructure at Skookum Digital Works. We have an amazing team of .NET developers who also know how to slang up-and-coming open source code, so we wanted to specifically share our .NET workflow and the types of projects which benefit or require .NET
.NET & TeamCity
In some of our recent .NET projects here at SDW we've been taking advantage of TeamCity. For those of you who don’t know, TeamCity provides us with a continuous integration platform. What the heck is a continuous integration platform? I'll give you the deets and explain why it makes our lives easier.
The TeamCity platform monitors SDW’s Git repositories for new code commits. Once something new is committed, TeamCity retrieves the latest code and attempts to perform a build. The build runs locally on the TeamCity server using a local install of the .NET framework (We are using .NET, but TeamCity can be used for some other platforms also). You can setup multiple build machines and Windows, Linux, and OSX all work as build agents.
The benefit of continuous integration is that within minutes of someone checking in some new code, you immediately know if you have a build-able code-base. This is awesome, because it keeps developers in the know about what commit caused the build failure and who committed that code. This way developers can quickly get a failing build back on track, without having to spend time going through source control commits finding the broken code.
Continuous builds are great and all, but what if a developer commits some code that compiles just fine. Then that code changes some functionality that breaks logic the overall application is depending on? That’s where unit tests come in to save the day. In our .NET projects we implement unit tests that verify our application functionality, and with our handy dandy TeamCity installation we can verify that with every code commit. Like continuous builds that happen on each commit, TeamCity will also run the unit tests for the project on every code commit and provide great information about why a failure is happening.
Now, if a developer changes some functionally that is core to the application but forgets to run the unit tests on their machine, TeamCity will let us know if a unit test isn't passing. Also if you want to see how much of your application is covered by your unit tests, you can add some code coverage statistics (through JetBrains dotCover). This can be done for free by just leveraging the built in TeamCity version of dotCover without having to separately purchase a code coverage tool.
So now we have a buildable code base, and we know stuff is stable because all our unit tests have passed. Who’s going to deploy the thing? TeamCity of course. TeamCity can be setup to deploy to a number of environments using various deployment scripts.
Our setup uses a PowerShell script to deploy our Development and QA git branches to our Windows Azure servers. With this power, we always have the latest stable code in an environment that is ready for testing. Also, developers don’t have to worry about taking the time to push code to the test environments to keep them up to date. If you're interested to see how this deployment works, we got our guidance from a blog post on Scott’s Blog.
In addition to deploying applications, TeamCity support publishing NuGet packages directly. More on this in part 2 of our .NET series.
Code Quality and Consistency
Finally TeamCity additionally supports FxCop and Resharper inspections out of the box. Now your team can work with the default best practices and whatever naming conventions you wish to support. You can setup the build to fail or just warn that the current code is not meeting your team’s coding standards.
While it’s fun checking out the overview page TeamCity provides in its install, but who wants to keep that thing open all the time to go check for build failures? That’s where setting up TeamCity to send emails to certain users on build failures comes in handy.
There are a number of settings you can subscribe to, but I think the sweet spot is getting emails on the first failure and then the first success after that. This way you are not getting spammed with all kinds build success (or failure) emails, and you’ll always be in the know on whether or not the code base is in a good state.
Continuous Integration has great benefits that can help developers be confident about the status of their code base. It also provides software developers significant time savings while building, testing, and deploying new features.