Rolling back a change set

Recently, I was working on a TSF Team Project project that had 2 branches.  I was continuously merging my trunk with each of these branches, as all three projects moved forward.  Recently I was given the go ahead to merge one of the branches into the trunk.  After checking and rechecking, I did this.

After about an hr after I had merged one of the projects into the trunk, I was, as usually happens, asked if I could make a change ASAP and release (in a way that would have the least impact on testing resources).  This meant that I needed release a version of the code that mirrored the current Production environment as a base with the necessary changes.  My first thought was that I would grab the change set, update the code, build on my local and release that.  However there was a gotcha, there was a requirement to have the build that was deployed done on the build server (with the TFS auditing of changes etc).

Anyways, I grabbed the required change set, made the changes, tested it locally, then checked it in, and released the result from the build server.  After checking that the release worked, I handed it over to the testers.  I then re-merged the code with the other 2 branches (luckily I hadn't deleted the one that I had been told to move into the trunk) so that they had the latest change.  Now, in TFS, merges use code on the server to merge, not code on your local (at least as far as I can tell).  As I was reviewing the changes and resolving the conflicts, I was seeing code from the trunk that included the branch I had merge into it.  Needless to say I got to wondering what had been built and then released to UAT.  I grabbed a tool to review the binaries that were in the release, and it was based on the project that I had merged into the trunk!  There was code there that I knew wouldn't be tested, and as such could not be released as this would increase the risk the change was raising (testing only the features of any change can mean that other impacts of the change are not identified until a full regression test is done).

So, I was left with a dilemma, how can I revert to a change set and release that change set, using the build server and all appropriate auditing in TFS, without having to manually remove all untested code and create a greater risk?  Then, after some googling, I came across a post by Mike Fourie, which details one of the new features in the August 2011 release of the Team Foundation Server Power Tools.  TFS 2010 has the ability, though the command line, to perform a roll back.  This extension brings that functionality into Visual Studio 2010 with a usable UI.  Let me just say that this saved my weekend from being an entire coding wreck.  I was able to roll back to the required version, then re-build and re-release only what was desired.  I wont re-write how it works, Mike does that well enough, but here are some links:

Mike’s Post: Using Rollback in the Team Foundation Server Power Tools

Team Foundation Server Power Tools August 2011

I hope this helps others out there who are wanting to (or having to) roll back code to a previous version on the server.

Securing CMS

Only a short one today.  At work we had an issue that we needed to secure our CMS to only be available for internal access. I had a few ideas, but after some research I found something very cool that was apart of IIS (6 and 7).  There is an option to secure a site or directory (or application) to only certain IP's. Its called "IPv4 Address and Domain Restrictions".

The reason why I'm blogging about this is because this is an easy way of adding an extra layer of security to a normal CMS.  Most CMS's are available for running locally, and this means that they are something that can be easily access, and the code can be analysed.  From a security point of view, this is a concern.  To mitigate against this, securing the main administration directories (login etc) using the IP restrictions in IIS adds an extra layer to the security of the application.

The easiest way to use this is to deny all access, and then only allow the IP's that you want to access the directory (usually internal and one or two external IP's).

Hope this helps.

Changes to Facebook API

Today we had something interesting happen at work.  We had just implemented some Facebook functionality on a project that was ready for release, and just before it was signed off today, a final end to end test was completed.  Part of that test was to test some functionality with social networks.  When the Facebook functionality was tested, it failed.

The functionality was meant to pre-populate the message box with a message that the user updated.  On Wednesday this was working, and today it wasn't.  Lets just say that this caused a few questions to be asked and a few worried people moving the corridors.  How can functionality that was working one day break the next when we made no changes to the code?  After some searching the web (Google is mostly always your friend), I found my answer.  Let me break it down for you.

Firstly, we were using the Javascript Library, specifically the FB.ui functionality. Using the Feed dialog box, we would place our user augmented message into the message box, which the user could then update and publish on their wall.  Now looking at the reference from the Facebook developers page (seen here http://developers.facebook.com/docs/reference/dialogs/feed/ ) the message property is what we used to pre-fill the dialog box. As you can see there is a note on the property that states that the field will be ignored on the 12th July, 2011.  So why was it still working two days ago (3/8 to be specific)?

Before I go into that let me first look at the policy for Apps in Facebook. If you go to the policy page (seen here http://developers.facebook.com/policy/ ) and read section 4 sub section 2 it states that an app will not pre-fill any fields.  (Then in the following sub section it states that the user can give permission for an app to post on their behalf. That is a task for next week.)

So back to the question, why did it just stop working?  If I were to guess, and that is all that I would be doing, I would say that Facebook just got fed up with people not looking at the policies and following them.  Apps should only pre fill the form when the user has done it some where else in the work flow.  I would say that there were plenty of apps that just didn't follow the rules and they just decided to enforce the rules.  And to be honest, I have no problem with them enforcing their policy.

Now, what is the lesson learned from all this?  Is it that we should not trust Facebook?  I would say not.  For me? The lesson is that when you are using third party services you need to be aware that what you don't control what happens with them.  You should intermittently test the services, just to make sure that they work as expected.  That is if you want to make sure that your sites and applications maintain the functionality that you build them with.
Hope this helps!

Something Different

It has been some time since my last blog post, and this one is not going to be along the same vein as normal. I will try to post something relating to my completing the underived version of the JOCU project, but work has slowed to almost a crawl as I am in the midst of work around the house (my computer is currently in pieces in the hallway, and I am using it mainly though my phone, not ideal for coding).

So, if I'm not going to relating something code related, I hear you ask what do I have to say?  Well, I have been playing with my phone (I have a Samsung Galaxy S i9000) and came across Darkys ROM.  Now, never having looked at custom ROM before, I was cautious as to whether this was a good idea or not.

Well, I must say I am impressed.  I have always know that my phone had more grunt than it used, like it was being restrained.  After setting up Darkys ROM, I can see a definite performance improvement.  There is instant response to touch input, as a result of using the 9.5 ROM, I am on Android 2.2.1, which has it’s own improvements.  Overall, I am very happy with my phone.  I mean, I was happy before, but now more so.  I even still have access to the built in Samsung Apps.

Something to note though, doing this has it’s risks. The Galaxy S is one of the few Android phones on the market that you can brick.  I also performed the update on my little brothers phone, and while the end result was the same, the process was not the greatest, a few times I thought I had bricked his phone.  But, in the end I got it working.  Doing this is at your own risk.

Now for the links:

Darkys Rom Home: http://www.darkyrom.com
2.2 – 2.2.1 install process: http://www.darkyrom.com/community/index.php?threads/guide-installing-darkys-rom-on-2-2-2-2-1-i9000-i9000m-only.1041/

I did an install from 2.1 to Darkys 9.5, but that one wasn't so smooth (my little brothers phone), so I wont post that here, I recommend that you use Google yourself.