Check-in policy that uses BuddyBuild

Apr 22, 2009 at 11:14 PM

Hi Guys,

Great job, I really enjoy using your application.

I wondered if there is a quick way / implementation to use BuddyBuild on a Check –in policy so every check-in action will trigger build through BuddyBuild after collecting all the pending changes and shelve them.

Thanks in advance,

Shmulik

Coordinator
Apr 24, 2009 at 8:13 AM
Hi Shmulik,

Thanks and glad you're enjoying using the tool.

Regarding your question, no there is currently no way to do this through the tool. The idea/suggestion is great. This is actually similar to the way the VS/TFS2010 gated-checkin feature works.

I am going to do some research on how easy it is to incorporate this feature into the tool (and utilize the existing Buddy Build Check-in Policy), and I will reply back to you on this thread early next week.

Thanks for the suggestion, and please keep the feedback coming.

-M
Apr 26, 2009 at 2:41 PM

Hi mojallou,

Thanks for your quick reply.

I already start to implement it by myself.

The policy structure is:

1. Shelving all the changes that I collect during the C-in action.

2. Passing to BuddyBuild the arguments that he needs and starting a build.

The problems that I occurred during my implementation was that I didn’t find "nice" way to actually cancel the C-in action, so after shelving my changes if I  want to leave the development environment as before c-in and only start a build on his pending changes I need to do one of the a below:

a. Undo the changes in the workspace – the problem with this solution is that I don’t really want to Undo the user changes but actually leave the workspace as is.

b. Return policy failure – also not very good option, because, the user can override it and I want to prevent it.

Do you know if there is a way to cancel the C-in action differently??

When I'll finish creating the policy I'll be glad to upload it to your project – if you want so…

Thanks in advance,

Shmulik.

From: mojallou [mailto:notifications@codeplex.com]
Sent: Friday, April 24, 2009 10:23 AM
To: shmulik segal
Subject: Re: Check-in policy that uses BuddyBuild [BuddyBuild:54183]

From: mojallou

Hi Shmulik,

Thanks and glad you're enjoying using the tool.

Regarding your question, no there is currently no way to do this through the tool. The idea/suggestion is great. This is actually similar to the way the VS/TFS2010 gated-checkin feature works.

I am going to do some research on how easy it is to incorporate this feature into the tool (and utilize the existing Buddy Build Check-in Policy), and I will reply back to you on this thread early next week.

Thanks for the suggestion, and please keep the feedback coming.

-M

Read the full discussion online.

To add a post to this discussion, reply to this email (BuddyBuild@discussions.codeplex.com)

To start a new discussion for this project, email BuddyBuild@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Apr 26, 2009 at 2:41 PM

Hi mojallou,

 

Thanks for your quick reply.

 

I already start to implement it by myself.

 

The policy structure is:

1.      Shelving all the changes that I collect during the C-in action.

2.      Passing to BuddyBuild the arguments that he needs and starting a build.

 

The problems that I occurred during my implementation was that I didn’t find "nice" way to actually cancel the C-in action, so after shelving my changes if I  want to leave the development environment as before c-in and only start a build on his pending changes I need to do one of the a below:

a.       Undo the changes in the workspace – the problem with this solution is that I don’t really want to Undo the user changes but actually leave the workspace as is.

b.      Return policy failure – also not very good option, because, the user can override it and I want to prevent it.

Do you know if there is a way to cancel the C-in action differently??

 

 

When I'll finish creating the policy I'll be glad to upload it to your project – if you want so…

 

Thanks in advance,

 

Shmulik.

Coordinator
Apr 27, 2009 at 12:06 PM
Hi Shmulik,

I'm glad to know that you have already started working on the implementation.

As you have pointed out, there are quite a few challenges that make the check-in policy method of enforcing gated check-ins a tricky endeavor. One of the reasons is that check-in policies are not preventive. They just alert you to the violation, but as you mentioned, you can always override the policy and provide a message justifying that.

Also, even if you go ahead and manage the check-in from within the check-in policy, by checking in first, you might end up invalidating the pending changes collection. I haven't tested that, but I suspect it can affect the check-in if the files are actually checked in and there are no changes.

If you want to really enforce gated check-ins, one way you can achieve that is by:
1) Disallowing check-in for the contributors group (or whatever group you might have your developers belonging to).
2) Have developers perform a gated check-in using the Buddy Build tool. If you use the Buddy Build web service, the buddy build requests will use the Build Service account's identity.
3) Once the buddy build succeeds, the shelved changes will be checked in by the Build Service account on behalf of the developer. The developer will still get credit for the check-in since the author field will be set to the developer's account. You can also choose to have the shelveset deleted upon check-in as it is not needed anymore. The changeset has the changes.
4) If the buddy build fails, the developer still has access to the pending changes in the shelveset.

This way, you guarantee that no check-ins will bypass the buddy build. However, this method cannot be applied to all development environments. Personally, I do not recommend this approach, as I would like to give developers the ability to always check in code to feature branches, but limit their ability to check-in to product-unit branches (integration branches) and to the golden branch (Main). Also, there are a few other pieces that you will still need to add to compliment this; one of those pieces is adding the ability to alert the developer that the queued gated-checkin or a buddy build has been completed since this action is asynchronous (you don't want a developer to wait for the gated check-in to finish - this might work on a small project, but for many projects where the codebase can take from a few minutes to hours to build/delpoy/test, the wait time might be unacceptable). I plan to add the buddy build alerts feature fairly soon.

Please let me know once you are done with your implementation. I am interested in how you might end up tackling those challenges.

Thanks,
-M