CI

Continuous Integration – Test Environment

September 4, 2010 CI, Environment, UnitTesting 6 comments

Couple of days ago I’ve been on CI seminar, where guy had been talking about concepts of the Continuous Integration and at some moment mentioned about testing environment and it suddenly dawned upon me and I would like to share my thoughts on this.

Two of many concepts of the CI are:

  • Have repository with all needed to build product on the virgin machine using command line.
  • Unit Tests, Integration Tests and Deployment should run on environment similar to production.

Feel the difference?

Ok, why do I ask about this?
Maybe a week ago we’ve moved to approach that builds sources and runs unit tests on absolutely virgin machine. Simply saying, nothing is installed into GAC, except of maybe .net framework. Everything needed we take from library folders under source control. And I agree that is really good thing. Compiler is also ok to build projects when they have reference only to root assembly in folder of other assemblies of some particular component. BUT, when you execute your code (run tests) CRL tries to find assemblies in execution folder and then in GAC. Since we have nothing in GAC, we should ensure that everything gets copied to execution folder, and here we dive into issues.

Fixes

In case of simple referencing this is not a big issue. You just should be as a spider and catch what is missed on enigma CI build machine. In some cases this is very trivial – you see System.IO.FileNotFoundException, in other cases it is not obvious.

Interesting trick

Here is one of tricts that we were needed to apply to make UT happy:
Since dll-s like sqlceme.dll are part of SQL CE, but are not CLR dlls  we cannot reference them. So we add them as link in your project and then change Build property to “Copy Always” to have them in bin.

There were some other tricks we were needed to try. They are simple, but there are many.

Main Question is still remaining

All that is not main intent of this post. Main is this: Do I really need to do this. Why is this correct?

And if we are so dedicated to CI, then I would like to know also what are we testing? That our code is able to run even if none of 3rd party components are installed?

I still have some doubts, maybe I’m wrong. I would really appreciate any of your thoughts, comments that will help me figure it out and find the right way.

For fun (but maybe will get lucky) I also asked Martin Fowler in twitter:


6 comments

KE – Day Forth – Continues Integration

August 12, 2010 Career, CI, Opinion No comments

For today it was planned to learn SQL and Continues Integration. In this blog post I’m going to express few thoughts on Continuous Integration. Only thoughts, because you can read comprehensive articles on it over the internet, like this one written by Martin Fowler.

My definition of CI:

Continues Integration is the way to keep an eye on the system your are building collaboratively with other guys, when everyone injects their work frequently.

I took picture somewhere from web, since I like how it illustrates CI

Few main suggestions on introducing CI:

  • Make sure that all sources needed for build are withing one Repository accessed by developers
  • Any developer should be able check-out sources on virgin machine and be ready to go
  • Everyone does commits regularly (once a day as a must), if someone complains about this you should mentor and convince him
  • Build is automatically started on commit event
  • Build should be as fast as it can
  • If build couldn’t be fast you should consider sub-project builds and primary-secondary builds
  • Developer is responsible for his commit so he should verify feedback from build system to see if build was ok and if tests passed
  • Create continuous deployment process to the environments close to production, say once a day
  • Execute automated tests on deployed system
  • Consider using some CI engine, like Hudson

And some thoughts about blind architectors

When, I came to the project and I faced lot of difficulties that project had, like having sources under different repositories, having not automated procedure of builds, also when someone failed build, everyone knew about that next day and all QA work was stopped; lot of complains about merging sources; dry applying sources to diff versions procedures. None knew what is going with project till next day! I was junior at that moment I did not know about CI, but, hey where our architects have been? Thanks to efforts of new fresh architects we’ve got CI and it applies to our project very smoothly. What is left is to convince devs do committs more often and cover everything with Unit Tests. (But that has also something to do with our project specifics.)

Why didn’t they consider introducing CI earlier? This is mysterious question, I do not understand. There should be definitely something significant (like CI) that we can improve!


No comments