The Bolla Blog - All Comments

re: A Better Continuous Integration + Version Control System?

Matt Baker — Sat, 21 Aug 2010 19:00:38 GMT

So I was thinking about this again for some reason last week and it occurred to me that this could be an extension of continuous testing. There are already systems you can set up that monitor the files in your source tree for changes (like JUnit Max, and I've used something in Ruby) and then run all your tests, notifying you if something is broken. Why not commit if all the tests pass? The system already has a state for that anyway.

Either way, I think what scares most people (myself anyway) is corruption of their working copy or the danger of losing their place/work due to changes their VCS client is pulling down without being asked.

Could this also create a lot of noise in your commit logs? Instead of changesets there would effectively be a checkin each time you save a change to a file and the tests pass.

NHibernate 2.0: Changes Overview

Mirrored Blogs — Fri, 05 Sep 2008 04:42:11 GMT

My post .NET Framework 3.5 SP1: Changes Overview on analysis evolution, structure and quality of the

NHibernate 2.0: Changes Overview

Community Blogs — Tue, 26 Aug 2008 17:45:45 GMT

My post .NET Framework 3.5 SP1: Changes Overview on analysis evolution, structure and quality of the

NHibernate 2.0: Changes Overview - taccato! trend tracker, cool hunting, new business ideas

Tue, 26 Aug 2008 17:14:55 GMT

Pingback from NHibernate 2.0: Changes Overview - taccato! trend tracker, cool hunting, new business ideas

NHibernate 2.0: Changes Overview

Patrick Smacchia [MVP C#] — Tue, 26 Aug 2008 17:01:07 GMT

My post .NET Framework 3.5 SP1: Changes Overview on analysis evolution, structure and quality of the

View to Presenter Communication(转)

江南白衣 — Sat, 02 Aug 2008 11:41:38 GMT

Alright, I've purposely hid the View to Presenter communication in my previous posts on Supervising Controller and Passive View because I thought that subject was worthy of its own post. As I see it, there are 2 1/2 basic ways to communicate screen events

re: C# 4.0 Feature Request: "??=" the Lazy load operator...

AK — Sat, 12 Apr 2008 03:40:24 GMT

Dude we are already so close with C# , dont add FLUFF.

Add STUFF

return _MYSERVICECLASS ?? (_MYSERVICECLASS = new MyService());

public class MyService

{

public int Count()

{

return 10;

}

public partial class Form1 : Form

{

MyService _MYSERVICECLASS;

public Form1()

{

InitializeComponent();

}

private int GetCount()

{

return MYSERVICECLASS.Count();

}

private MyService MYSERVICECLASS

{

get

{

return _MYSERVICECLASS ?? (_MYSERVICECLASS = new MyService());

}

private void Form1_Load(object sender, EventArgs e)

{

MessageBox.Show(string.Format ("{0} count , service is null {1}",GetCount(),_MYSERVICECLASS==null ));

}

re: A Better Continuous Integration + Version Control System?

Sean Chambers — Sun, 06 Apr 2008 15:51:09 GMT

I feel the need to chime in here as well. Interesting ideas but like everyone else I think auto-commit is a very bad idea.

The last step of the TDD mantra is refactor. Therefore, if an auto-commit is happening every green step, then you never have an opportunity to refactor your tests/code to support the new test. In addition, I write 10-20 tests between commits because one commit from my workstation often includes a set of tests that test a specific portion of the project, but just a single test per commit.

Some of your ideas are great though, opening your IDE and it automatically getting the most current revision from SC is a good idea, maybe with an alert window in case you don't want the most recent revisions however.

re: A Better Continuous Integration + Version Control System?

Greg Young — Fri, 04 Apr 2008 21:57:04 GMT

While this sounds pretty good and reasonable you are asking your development environment to do the equivalent of realizing when you want a beer and walking over to the kitchen to bring you one.

btw: commit on tests pass only works if I write tests first ;-)

re: A Better Continuous Integration + Version Control System?

keith — Fri, 04 Apr 2008 18:21:18 GMT

"The other scenario is when Dev A and Dev B are editing the same block of code, which leads to merge conflicts. In this scenario "CIVCS" wound't be able to not automerge the changes but instead could indicate the merge conflict by putting a "merge confilct" icon in the gutter to the left of the relevant lines of code."

but then i'm forced to resolve the conflict _now_ instead of when i'm ready to (when my code is finished and ready, by my definition of ready, for integration)

disruption and context switches lower productivity substantially, on average.

re: A Better Continuous Integration + Version Control System?

Steve Campbell — Fri, 04 Apr 2008 15:02:22 GMT

I'm a little wary of the auto-commit idea - explicit commits are important for lots of reasons, not least of which is identification of atomic changes that need to be integrated to other branches of the code.

The idea of the working copy being auto-updated is ok for me, but may not work on larger projects that contain multiple solutions, in such a way that for the new working copy to function, I would need new binaries too, and possibly even a database migration script. Also, if a programmer is spiking on something, then they may throw away changes - integrating too early can be a bad thing then.

That said, I can see scenarios where the idea has merit - perhaps in the beginning stages of the project, where we are growing from nothing to something. Often, team members have to wait around while someone else works on a core feature. In that case, perhaps it would be good to get a more rapid integration cycle.

re: A Better Continuous Integration + Version Control System?

Jim Bolla — Fri, 04 Apr 2008 13:40:44 GMT

"Many times my tests 'pass', but I am not done with either the test or code under test. "

If you're writing new code that is not yet integrated into the entire system, then your teammate receiving this partially complete (but compiling and test passing) code should not disrupt him.

If you're modifying existing code by refactoring or adding functionality but the tests all pass, then this should still be safe code for your teammate to use.

If you're changing the behavior of code, and then changing the assertions in the tests for that code, then there is a chance that these changes may cause problems for your teammate.

Derik, can you think of any other scenarios where a committed change may be disruptive to another teammember?

So far I'm seeing two negative reactions:

"I don't want my changes automatically committed"

and

"I don't want my working copy automatically updated/"

I think auto-committing is a great idea. It means tested changes are available for integration sooner.

I can feel how auto-updating could be disrupted. This is probably where the tools need to work well to not disrupt the developer. I get this. But from my experience, at least 90% of the time changes could be merged in silently and successfully.

re: A Better Continuous Integration + Version Control System?

Jim Bolla — Fri, 04 Apr 2008 13:10:15 GMT

"developers need a stable base upon which to make changes over time"

I agree. But I think that a code base that always compiles and passes a substantial battery of tests IS a stable base.

"just b/c tests pass doesn't mean your changes are compatible with my changes"

Assuming adequate test coverage and all the tests pass, then there's a high chance that the changes ARE compatible, because passing tests mean that the code still meets all of the assertions established in the tests.

"have you never worked on a project where multiple ppl are changing the same files?"

One scenario is when two people are editing a file in independent ways. Dev A is changing methods A, B,C and Dev B is changing methods X, Y, Z. This type of change should be transparently mergeable. The other scenario is when Dev A and Dev B are editing the same block of code, which leads to merge conflicts. In this scenario "CIVCS" wound't be able to not automerge the changes but instead could indicate the merge conflict by putting a "merge confilct" icon in the gutter to the left of the relevant lines of code.

"the goal of CI isn't to automate your entire workflow."

Perhaps *my* goal is in fact to automate my workflow. There are different workflows that work well for different teams. I'm simply suggesting an alternative that I think has some potential.

" that mindset is a slippery slope towards code generation and robots programming."

Code generation can be a powerful tool when used appropriately. For example, we generate DTO classes based on our database schema as part of our data access layer. This gives us a certain level of compile time validation of our data access. Our NUnit tests cover the rest. Reshaper templates are another form of code generation that is quite handy on the micro scale. And a web control is nothing more that a code construct (C#) that generates other code constructs (HTML + JS)

re: A Better Continuous Integration + Version Control System?

Derik Whittaker — Fri, 04 Apr 2008 10:31:58 GMT

I don't like the idea of a passing test updating VC or kicking off CI. Many times my tests 'pass', but I am not done with either the test or code under test. I could have logic that is mid cycle and checking everything in could foobar the next guy trying to use my code.

I see your point, but I think that check-ins have to be a manual, with intent process.

re: A Better Continuous Integration + Version Control System?

keith — Fri, 04 Apr 2008 03:18:41 GMT

automatic commits and updates is such a horrible idea.

developers need a stable base upon which to make changes over time, which they sync up to the trunk when they are prepared to, not when their IDE chooses to. just b/c tests pass doesn't mean your changes are compatible with my changes. have you never worked on a project where multiple ppl are changing the same files?

the goal of CI isn't to automate your entire workflow. that mindset is a slippery slope towards code generation and robots programming.