Pages

Showing posts with label .NET Framework. Show all posts
Showing posts with label .NET Framework. Show all posts

Cruise Control .NET

Our development team has finally decided that each of us individually pressing 'F5' in Visual Studio is no longer an effective build system.  Another dev group in the building took up Cruise Control.NET and Octopus at the end of last year.  I've starting investigating its potential for our team as well.

So a quick rundown of our current situation:

  • We are actively developing and supporting a web application that allows users to login and complete work from IE 8+ browsers.  We are currently doing work to support both Firefox and Chrome as well, so there is ongoing testing as we develop new features.
  • Our main application uses a viewer that requires an ActiveX install on IE version 8, but uses an HTML5 canvas object for the viewer on IE9+.  
  • One member of the team has developed a central user authentication page that is driven by customized JQuery grids.  It's complex and its integration into our main application has been bumpy.  The idea was single sign on, but it isn't quite there.
  • Data is made ready for user consumption by a Windows Service that runs on various virtual machines and writes to a set of project-specific databases.  We receive some data by web service, a replication process from another set of databases, or even flat-file.  It's a moderately flexible, but aging service application.
  • We have been using SVN for source control for the last couple of years.  There are still those on the team that struggle to use it within the standards that I developed for our group, but we're getting there.
  • We've just begun to use NuGet Package Manager for a number of dll's and there is some confusion in our team about which package files are appropriate to be checked into source control.


    We have a few goals in making this change to our build processes.  First, we want a simple and repeatable build process that is scripted.  We have individuals on the team that have built various pre and post build scripts into their local machines and it creates issues when source files get checked into the repository. 

    Second, we have a new hire whose specific charge is developing a suite of automated tests for our application.  He is making progress and we would like to integrate his smoke tests into the build process.  Once a build command is sent, we want to kick off his set of tests and return a pass/fail for each of them.

    Third, we want to approach our development task list with confidence.  If the source is continuously being built and tested, we should be able to refactor existing code and develop new features with the knowledge that we are working off a solid code base.  I'd like to get us to a world where a developer's commit to the SVN trunk automatically kicks off a build process and gives us immediate feedback.  

    Cruise Control seems like a good solution. The challenges that I foresee based on my research would be as follows:
    • Setup cost.  The configuration and scripted build will take time and effort to create.
    • Our current application is built in a way that requires fairly brittle testing in order for it to be worthwhile.  
    • We do not currently have a set of scripts that will create a development environment from scratch.  Getting a new hire up to speed is time consuming.
    • And of course the reluctance of the team to make a change to our current process.  It's slow and painful, but it's known and we make it work.
    I've installed Cruise Control v.1.8.3 on my local machine.  There are some permission issues to resolve, but it was relatively painless to setup.  Next steps are to associate this with a local project to test out some of its features.  

    Closed-Source? There's An App For That

    I recently read an article on Gamasutra about developing on closed-source frameworks.  The author posts some interesting pieces on the site and I like to follow him, but this write up rankled me a bit.  He suggests some good reasons for why you should only build on open-source platforms.

    I like working with .NET.  It streamlines details of what is going on under the hood so that I don't have to worry about as much.  Maybe the article annoyed because I agree with his principles while I ignore them in favor of not having to dig deeply into the underpinnings of popular .NET frameworks.  Why poke around in the guts of XNA when it lets me get started on a game idea quickly?  Who cares how WCF works its magic when it allows me to ease the pain of bringing a handful of standard web technologies together in my distributed applications?

    While there are real benefits to using a framework out of the box, I think a deeper understanding of the frameworks we take for granted in .NET is a good thing.  Sometimes you want to open the hood and see what's going on.  I did a bit of that with Resharper before it became a commercial enterprise, but I've been lazy lately.  There's really no excuse for that when there are some easy to use open source alternatives such as ILSpy and the upcoming dotPeek.

    I've started using ILSpy and it's a nice simple tool.  Download the binaries and run the exe to start decompiling.  Enjoy turning over the rocks :)

    Decompiling a C# type in ILSpy