Showing posts with label GIT. Show all posts
Showing posts with label GIT. Show all posts

Friday, 14 March 2008

Scaleable unit testing and continuous integration in an agile team using GIT

I like agile development, it works, but it does need some pretty clear guide lines and rules. It also needs very good testing systems to ensure no developer breaks anyones elses code.


Up until now, I have been using the same tools as everyone else.


SVN, perforce, CVS, etc... we all know this type of source control management system.


We all know how these systems work.


I take a task, I write my unit test, I make sure it fails, then I write my code until the test passes and all other tests pass as well. Then I can commit my code.


When I commit my code, the continuous integration system kicks in, re-builds the application, runs all the units tests, and then the functional tests.


It is really cool. Especially if you have been developing for some time and remember 'the older days'.


The 'Old Days' when we worked alone were much easier, but we need teams now, and we must have ways to manage and control working together.


However, about half the time, when I check in my code, I break something, and the continuous integration system bleeps loudly and displays an embarrassing photo of me.


So now I have to fix the problem. And that's ok.


However, with any decent sized team, you now have a single point of failure.


The build server itself.


Everything merges at this point, and many regression mistakes are only discovered when the code is checked in. This means that the primary development codebase is now broken.


And this tends to happen often, every day.
A right pain if you are running a tight release cycle.
There is no way you can pass broken code to QA.


It gets even worse, when tasks are larger, the changed code coverage is large, and it has been quite a few days since it was checked out.


Now, it is possible, and good practice, to do a checkout before checking in. But how many times have I seen this forgotten in the rush to get a release ready.


So that's the problem.


 


The solution that I have recently converted to, is GIT.


This distributed SCM, at first seems rather primitive, but on further examination, this primitive nature hides a great deal of raw power.


Distributed SCM means every developer can commit to their own repository, so they can roll-back their own code if they go in the wrong direction.


Distributed SCM also requires much better branching and merging.


It is simple to create a distributed branch for a micro-project team, each developer can now clone this branch, work locally, commit locally and then check their code back into the branch.


The micro-project team leader can now do code review, unit testing and functional testing, before committing the completed project back into the primary codebase.


So now, at any point in time, you can take a copy of the main codebase and pass it to QA for testing and release. Knowing for certain that only working code ever makes it into the this codebase.


This allows you to move to a fast release cycle. A new feature has been added. Now you can test and release knowing everything will work.


In effect, you have moved the larger scale unit/functional/regression testing further back into the development process.


What you also managed to achieve, is secure asynchronous micro-project development, so each micro-project team can now work independently while still being agile.


And all the effort ends up in a single unified codebase that works!


This is the secret to scalability in agile development.


 


The title of this little note does promise to let you in on how to integrate the unit and functional testing of continuous integration into GIT.


I love this, it is so simple.


Because GIT is so primitive, it runs scripts, that actually sit in the repository itself.


All you need to do, is edit the scripts to add your testing.


Even better, you can set it up to run pre or post any command.


e.g.: run unit tests post-commit.
e.g.: run functional testing post-merge


etc...


With a little thought, you can have an entire workflow mapped out that will only allow unit tested, function tested, regression tested and codebase merged micro-projects to be committed to the primary codebase.


As far as I can see... this is as close to the holy grail as we have ever been.


Have fun.

Tuesday, 4 March 2008

GIT on Windows...are they forking already?

I already have cygwin installed, with GIT.


I have just been trying the mingw32 based version of GIT.


Mostly because I wanted to see the QT based QGIT, which will work directly with the mingw32 version of GIT.


What I want to point out, is that these two versions seem slightly incompatible...


A full commit from cygwin, comes up in mingw32 as all files modified and needing commiting.... but this have been because I started things in the middle of a commit.


another point that concerns me, is that mingw32 GIT automatically converts LF to CRLF, ie: it makes things windows specific... As I develop on windows to use on linux, that is a problem.


Something is wrong if these two are unable to communicate properly, especially as they should be using the the same repository files, ie: .git folder.


I hope they get it together soon.

Friday, 22 February 2008

GIT on Windows XP (winXP)

I am still experimenting with this... but...


You can get GIT running by simply downloading and running the cgywin installer.


Run the installer in standard configuration, and obviously include GIT... but also make sure to include VIM, as this is required to edit the comments. (PERL is required, but should be in the default installed packages. Make sure it is.)


Finally, you need to fix the whitespace issue caused by the difference between UNIX and WINDOWS carriage-return/line-feed. If you edit a file in a windows tool, it will leave an extra line-feed that triggers the error. The fix for this comes Capi's Corner...


Edit .git/hooks/pre-commit and comment the following lines(c. line 58).




if (/\s$/) {
bad_line("trailing whitespace", $_);
}


You should now be able to commit properly.

Wednesday, 20 February 2008

Why Git

I suppose the first thing you should do is watch the videos.


Here is Linus Torvalds explains GIT philosophy to googleTech:
[video]http://www.youtube.com/v/4XpnKHJAok8&rel=1[/video]


And Randal Schwartz with more details about using GIT
[video]http://www.youtube.com/watch?v=8dhZ9BXQgc4[/video]


You should now know enough to realise why GIT....


If you are still in egypt... de nile... then here are some thinking points.


these are coming as soon as I organise my thinking....