The management of software development is all about using scarce development resources to satisfy unlimited wants of the customers.
In the situations with limited resources (time, budget and skilled labor) the only way to get more out of nothing is to use these resources more efficiently. One way of achieving such a goal is about better automation of some development processes and leveraging the opportunities provided by the integration of different development subsystems.
Here some examples of such automation and integration:
- Integration server tags SVN on every production build, runs the normal routine, then packages all redistributables in a separate folder (matching build label) that is accessible via FTP (side effect is that all production packages are saved somewhere and could be easily retrieved if such need arises).
- Integration server uses svnRevisionLabeller (or any other similar plugin) to retrieve revision number from the SVN, incorporate it into the proper 4-digit version and build .NET assemblies with that.
- Integration server updates version flag on every production release. Production systems have module that checks this flag regularly and informs user of the new version.
- Integration server updates Click-Once publication on every production release and the client application updates automatically after the next launch.
- Keywords (feature from the Subversion) are used to populate attributes of some business classes with the “last changed” and “latest revision id” values on per-file basis. These values are retrieved via the reflection upon the generation of some inter-development reports/statistics
- Integration server hosts continuous monitoring project that regularly checks the production systems, runs some sanity checks and reports any failures or deviations if they are detected
- Integration server checks commit messages before build and passes all encountered tags to the build script (i.e.: #RunAllTests, #DeployToTest, #CreateRelease, #SetVersion(1.2), #TestPerformance etc). Friend of mine used to do that on his projects.
- Integration server locates all issues/tickets that were closed since the last release build, marks them with the build version and either creates a link to the filter in issue management system (JetBrains does that) or auto-populates change log report (being delivered with the release artifacts).
- Integration server runs the unit-tests and captures screen-shots of all the presenters available. These shots are then labeled and framed nicely and are used to update the pictures in the product documentation (which is also gets packaged and processed on the release cycle)
- Production release creates Virtual Machine package with the pre-installed and pre-configured solution (could be used by testers and sales-people)
I’ve leveraged some of these scenarios (items 1 through 6) in different development projects I’ve been a part of (esp. in projects that were based on the xLim principles). On the overall such things do really reduce the development friction and have solid Return On Investment rate in increased stability and saved time. And they also reduce the risk that a mere mortal would make a stupid mistake while performing some mundane action.
Reduced development and release friction obviously promote faster development iterations. That shrinks the lag between the moment customers have requested some functionality and the moment they can inspect it (and provide feedback for the next changes).
Are there any time-saving recipes that have proved themselves worthy in your project and are not on this list?
NB: Obviously one must be cautious about taking any single item from the list and applying it to the specific development project. Specifics always matter and not all combinations will be worth it.
Here’s one more way to edit project files in Visual Studio (kudos to Jeremy Gray):
Microsoft Visual Studio 2008 Power Commands have “Edit Project File”:
This command opens the MSBuild project file for a selected project inside Visual Studio. It combines the existing Unload Project and Edit Project commands.
As you know, normally Visual Studio 2008 does not let you open *.csproj files from the current solution in the editor (for example, when you want to tweak the build process to compile these custom DSL scripts of yours). I used to resort to starting second instance of VS just for the XML editing with the IntelliSense.
However, as it turns out, there is another approach:
- Right-click on the project in “Solution Explorer” and select “Unload Project”.
- Right-click on the project again and pick “Edit [ProjectName]”.
- When you’re done with the editing, just hit “Reload Project”.
In this post I’m just kicking out one item from my “to do list“.
Being a developer means that you tend to stick to your keyboard instead of wasting time to reach for the mouse and do some movements. That’s why learning R# shortcuts could yield an immense productivity boost in your .NET projects. Same principle applies to the other areas outside your IDE as well.
Launchy (aka “Open Source Keystroke Launcher for Windows”) is just like your {Ctrl}+{N} Resharper shortcut for your Windows Operating System. And it is also extensible, skinnable and works. I’ve used HiddenMenu and PStart before, but this tool is way more efficient.
BTW, do you know, that you can type something like *Report in R# type search and it will work?
There is a great code coverage tool called NCover that collects information about the code statements visited during the test execution. It has turned commercial but last free versions 1.5.8 are still available for download (BTW, you can use this service to skip the registration phase).
Additionally there is a great utility NCoverExplorer that excels at parsing and visualizing these code coverage reports. It also provides means to generate HTML reports and integrate them with CC.NET. It went commercial, too, but the last free version is still great.
The only real benefit of the commercial (enterprise!) version for me was the ability to run NCover on 64 bit machine. Otherwise you would get the dreaded:
Profiled process terminated. Profiler connection not established.
Well, it turns out that you do not need to spend money on that. Here are the steps that worked for Windows Server 2008 64 bit (wasted 40mins on that):
That’s it.
PS: BTW, using Windows Server 2008 64 bit as the primary development environment turns out to be really enjoyable experience.
CPU cycles get cheaper and cheaper. Here’s a nice example: a linux cluster in a IKEA Helmer cabinet. According to the site it has 24 cores running at 2.4Mhz, 48Gb of RAM and uses just 400W (approx 186 Gflops). The cost is just $3500.
Now, if the tech keeps on rolling this way, how many new devs would really bother about sub-optimal GC or efficient codeflow in their code? Most likely the joke about having “processor core leaks” and “processor core collector” could turn true.
I’m really “deep in the trenches” right now due to two concurrent projects running. Nonetheless, here are just some quick notes:
- Avoid using DevExpress XPO for large-scale projects where the future requirements could change. It is extremely easy to get started with that, but in the long term your DAL could become a bottleneck in the process of the project evolution (flexibility is too limited).
- Do not use XPO 2 Linq! It supports only basic queries and has absolutely no documentation/matrix/test suite to validate and tell what’s working and what is not. Test suite of NHibernate 2 Linq is something I would expect to find in such a product.
- There is another option for the single gateway interface (as in DevExpress XPO) utilized by xLim projects. That’s the WCF 2 Linq project or any other analogue (there surely be more of these as the technology gets adopted).
- Some say that the combination of Final Builder and TeamCity is the most flexible for the integration purposes. Well, this could be true - FB even has tasks to deal with VMs.
Inspired by the abovementioned NHibernate 2 Linq test suite (it utilizes the power of MBUnit) I recently implemented a nice business test suite for the xLim2-2 application. Basically this is the test suite that re-uses connectivity and logic modules implemented with the help of Autofac IoC container (simple config is used to get them setup and running). The initialization happens in the global setup routine (supported by MBUnit). And then the actual tests just resolve some components/services from the main container (every test is running within its own container scope) and run simple assertions around these.
Example of an assert could be - “make sure that there are no critical errors in the system log”, “make sure that loose object references in the database point to each other” or “make sure that file store is in consistent state with the DB”.
So, provided you have the proper config and the compiled unit test, you just can point it to any production system and check its status in simple manner.
If we take the idea further, then these tests could be uploaded to the CruiseControl.NET to let them run against production on a schedule. And if something breaks - you’ll get the notification immediately (CC.NET will handle that).
Additionally it is easy to set up continuous statistics capturing via the same tech. So we get continuous system validation here and continuous system monitoring at the expense of writing just some validation tests and doing one-time setups.
Latest Comments