Over the last couple of days, I completed a first version of a Continous Integration environment. If you are not familar with what Continous Integration is, I would recommend an excellent podcast from Scott Hanelman.
I have a dedicated build machine setup that will be hosting two environments for performing build & tests, I'm going to test
I had installed the Build Component with TFS a while ago, configured it to run builds and this seemed pretty cool, but haven't spent too much time on this.
The CruiseControl.NET environment I created is fairly basic, but I was able to get it up and running within about an hour. Here is a summary of what is currently in place.
- CruiseControl.NET runs as a service and is configured with ccnet.config file.
- Within ccnet.config, I created a project that looks at source code within my TFS repository.
- When I check a file in to the TFS repository for the project I created, it get's all the source code under the node specified in the ccnet.config, then runs a task to kick off a build with MSBuild.
- A small application can be installed on our development machine that runs in the tray that allows you to check the status of builds, it also gives you notifications of when builds are completed or they break.
- In addition there is a web based dashboard that will give me a report of the latest builds.
I'm extremely excitied about using additional features that will allow for unit testing and functional testing as well as deployment. I'm going to compare the Microsoft TFS offerring with the CruiseControl option. In theory, if I build these both around the the MSBuild tool, I should be able to have similar build processes in both environments.
What experiences have you had with continuous integration or similar technologies?
Upgrading from Beta 3 refresh of TFS to RTM, was as painful as I expected (but probably my own fault). With great hopes, I downloaded the Team Foundation Server Upgrade Package and faithfully followed the steps within the document.
The first thing I learned when applying the update was the Beta 3 Refresh of TFS was incorrectly installed. I purchased a server off of ebay to have a dedicated machine running this software, however when I installed SharePoint services, I missed the step to install it with the "Server Farm" option. This created a named instances of SQL Server independent of the SQL install hosting TFS. When the TFSUpgrade utility attempted to apply the updates to the SharePoint databases, it failed since the upgrade was looking in the default instances. I moved the databases from the SharePoint instance to the default instance, and I think that was the cause of most of the problems.
To make a long painful story short here are the next steps I did to complete the effort...
- Ensure I had backups of all the databases involved (before and after I ran the TFS Upgrade Utility).
- Uninstall Beta3 refresh of TFS
- Attempted to install the RTM version, got SharePoint errors (stmadm.exe did not return zero)
- Attempted new settings in SharePoint for "Default Config" db, as well as the "Content DBs" for virtual servers.
- Uninstalled SharePoint, reinstalled with Server Farm option selected (this allows for TFS to manage the database configuration).
- Attempted to install RTM version again, got similar SharePoint errors.
- After trying different combinations, looking at the data within the STS databases, after about 4 hours I decided to just rebuild the box install TFS from scratch.
- This went well, everything worked as expected and within about 1.5 hours I went from a formatted hard-drive to an up and running TFS server (probably would have been quicker, but this is an older PIII Xeon @ 1.1GHz)
- For the moment of truth...I restored the backups of all my databases...DOH, when I rebuilt the box, I had thought hmmm, it was named SLNETPSQL3 before, let's name it SLNETTFS this time...big mistake!!! After I restored, all the data referenced the name of the original server SLNETPSQL3, I probably spent about an hour or two attempting to figure out how to change everything over, but no luck...
- Decided to just go ahead and rebuild it one more time, this time with the original server name. Again about 1.5 hours later I had a fresh install of TFS with everything working just fine. I made a copy fo the original DB's.
- Next I attempted to restore the original DB's, at soon as I did this, I couldn't connect to TFS with any of the users. So at at this point, I had about 20 hours into the upgrade and needed to get some work done to pay the bills, so I decided to just restore the databases from the fresh copy that I knew worked.
- I was in business, then I just restored the versions of my production TFSIntegration db to a different name, copied the tables tbl_projects, tbl_security_projects & tbl_security_objects for those projects into my new database.
- At that point, my projects came on line.
- I restored the TFSVersionControl database and all my source history got restored YIPPPPPEEEEE!!! (I had off-line backups of the source, but it was nice to be able to keep the source history)
- Next I had thought, ok let's get the work items in there...no luck here, there is data in the TFSIntegration database that needed to be tied to the data within the work items db, so this did not restore to work with my new version of the projects in the TFSIntegration DB.
- I tried for about a couple of hours to manually import the tables, but ran in to some F-Key violations that stemmed form the work items not being created for the projects (I think I know what I need to do to restore these, but again need to get some real work done to pay the bills, probably do another post when I get this completed.
Anyway - things are all well, I have a couple of legacy TFS projects that are limping along but useable non-the-less.
Has any one else had similar experiences?
*Note - Although my experience documented here wasn't too "pleasant" it is probably due to my lack of my prior knowledge on TFS configuration and architecture and learning on the fly. This was an excellent learning experience and the more I learn about the capabilities of this product, the more I like it!
I recently came across an interesting tool for looking at source code metrics SourceMonitor from Campwood Software. This tool looks at source within a set of sub-directories and gives you basic measures about your software.
The following are a sample of measures captured through this application:
- Total Source Lines
- Total Statements
- Percentage of documentation
- Complexity
- Block Depth
A very interesting chart is the summary one below; this gives you an idea of how well your source fits within a predefined set of measures.
When developing software, you need great strategies and tactics to succeed.
You may have an excellent vision on what you want to get to and a well thought-out approach; however if the developers writing the code mess up the implementation or don't follow the requirements your strategy will be meaningless.
On the other hand you could have the most experienced hardworking developers working on your project. If they get sent in the wrong direction based upon a faulty strategy either due to lack of experience, lack of experience with the technology, requirements that aren't clear, picking the wrong technology, methodology or incorrect architecture your project could be in real trouble.
Finding the right combination of strategy and tactics can be a challenge, however once the balance is achieved, your project is almost guaranteed to be a success!
Some companies look to technology to achieve this balance however this can truly only be found through experience and/or an effective mature process.
In most cases projects fail or fall short of expectations due to strategy type issues.
Visual Studio .NET 2005 provides a very powerful frameworks for performing web testing.
Here are some tips to make the most out of these features:
- When creating controls on your forms, make sure each control gets an ID even if these controls get created dynamically. This will give a consistant name for checking fields on post-backs. If you don't do this VS.NET generates a name like ctl00. If you move things around on your page, this may become ctl01 and your test will break.
- Besure to take advantage of Context Parameters, these allow you to quickly define constants to be used across tests.
Why the efficient coder?
Well - There are really a number of different motivations/categories to care about the idea of becoming an efficient coder see if you can pick where you're at...
1) You think you have an extremely stable position where you just show, up cut a little bit of code, not really deliver anything and pick up your paycheck, if this is you this blog really isn't for you...
2) You have deadlines that never get met, but these deadlines aren't really that important, if the deadlines aren't that important your job/department probably isn't that important and hense when the next round of lay-offs you might be a good candidate, if not you might by in category 1
3) You care some what about delivering your software on time and your project is understaffed so you're working 50-60 hours per week (an incompetant project manager/boss goes along way to put you into to this category)
4) You're a consultant and get paid by the hour...the more you can get done in one hour (and sell yourself) goes a long way to boost your hourly rate...would you rather work 40 hours at $100/hr or 80 hours at $50/hr?
Kevin
|
One thing that I've seen a number of times in a number of different clients is the following:
- A team decides on an approach
- The team spends considerable effort building support mechanisms for this approach
- The approach that was decided on turns out to be invalid
- The has to scrap all the support mechanisms built for this approach costing the effort days/weeks or in some cases months of time
There are two ways to avoid or minimize this type of problem:
- Make absolutely sure that the approach you are taking does indeed solve all your problems and doesn't have any "deal-breakers" that would invalidate using the approach.
- If you can be absolutely sure of the approach, try to build your support mechanism such that they are as generic as possible so if your initial design approach is invalid you don't have to scarp all your work.
The may seems obvious, but this is one of the bigger product killers I've seen out there. |
|
|
The Chaos Filter allows for identifying and capturing metrics on day-to-day assignments for a large number of knowledge workers. As processes are defined they are put into a "portal" that will be used as a dash-board to capture metrics as work is completed. Targets are established for tasks down to a fine level of granularity, if those targets are not met, that is OK in that they will be adjusted however and reasons are captured as to why things take longer than they should.
Once it is established why things are taking longer than they should, the process/job aids can be modified so that the next time the process is executed actual time may be closer than expected.
This same model can also be applied to the sales process. Reasons can be captured as to why sales are not be closed. These reasons can then be addressed.
An interesting challenge here is how to allow for an environment where the knowledge workers can feel empowered to suggest changes to optimze the process as well as try new things and make mistakes in an effort to be more efficient. The problem here is not where people try and not meet the targets for their processes/tasks but where people try to "game" the system and take advantage of a situation where processes are closely being tracked.
The key here is worker efficiency, not making people work harder. |
|
|