Lovin’ it already. And today was my second day at Nitor Creations. I got a new laptop (Lenovo W510/12GB mem, i7 quad-core!) with win7. Well, I have very little knowledge how to work effectively with windows so the inevitable happened and Kubuntu 11.04
stole the boot sector. Some issues with stability though, most likely due to NVidia drivers, which were at least partly solved by installing nvidia-current and running nvidia-xconfig and nvidia-settings as root. So far this has been the best work setup I’ve ever had, plenty of memory and CPU power, the OS I want and no prohibiting policies or idiotic restrictions. Just the way it should be. Anyway, had to make some loops to get Adobe AIR installed so that I could install Tweetdeck (sigh.). Skype was fortunately a painless installation.
Albeit slightly annoying, the tech issues are become fun in the end and after some struggles it was a joy to join again the Nitor irc-channels. So many like-minded geeks there (I was at the office, others were at the customer sites). And immediately there was a debate about mocks and unit test quality, just the way I like it. Smart people with different views, ideas and wide experience provides very fertile ground for tough discussions and a good place to test ones ideas. And a very supportive group it is. Everyone willing to help the new guy.
I think I’m gonna like this place a lot!
Day One.
Just configured Hudson to build my project. It was easy. After configuring Mercurial and Maven it was nothing more than triggering the build. I found an extremely helpful tool for maven projects, it is m2eclipse. It allows you to create Maven projects within Eclipse which is nice but for me the killer feature was the pom.xml editor!
Looking up dependencies is easy! Just add a dependency and m2eclipse will provide you a search. Start typing the dependency name and it will show you the results of its search. Select what you want with correct scope and you are done.
Now, time to get back to test-drive some features to my home experiment!
I’m on my winter holiday, Yay! I was thinking that I will spend most of the free time practicing my art of coding. I am not very familiar with maven, Hudson nor Sonar so I am planning to write a piece of software using all three of them.
It may seem odd that something as essential as maven is unfamiliar to me, but looking at my career it starts to make sense. I have been building software mostly with C and Perl in a legacy environment with in-house build systems so there has been very little use for maven. For continuous integration I have used QuickBuild and only scratched the surface with Hudson.
So, it is a good time to learn those tools now that I have some free time!
I faced a situation where I wanted to develop locally at home but still keep the sources available for myself on other hosts. For example, I am currently developing a TDD primer slideware and I have a simple example code base for a coding dojo that I wrote here at home. I want to be able to continue it at work too and then be able to sync it with my home laptop.
The problem is that I don’t want to run a Mercurial webserver at home (no proper hardware, just an old T42) or use any commercial service like bitbucket. I can’t run servers at work either due to firewalls and corporate policies.
But what I do have is a shell! And it does have Mercurial installed. So, off we go to setup a private code proxy that I can use as an intermediate storage for my work.
remote> ssh user@remote
remote> cd ~/my-repos/
remote> mkdir project
remote> cd project
remote> hg init
remote> exit
local> cd project
local> hg clone . ssh://user@remote/my-repos/project
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 6 changesets with 29 changes to 13 files
Just remember that clone assumes path relative to users home directory (that’s why there was so short path on the command).
After the first clone I have to manually run
on the remote to make it aware of the changes. Now I just edited the projects hgrc file on the remote to contain
[hooks]
changegroup = hg update
Now it updates itself when ever I push stuff into it again. That’s it, now I can easily setup and share with myself any repositories that contain source code I want access anywhere.
Ha, this is it. As funny as it is to hack everything together from the scratch, sometimes it just isn’t worth it to reinvent the wheel. So, the platform is WordPress. Just started to customize the layout and there are lots of things to learn from the features. Expect new pages in addition to my blog. I will also transfer my dj pages here. So, only one location to look for my stuff then :-)
Today I was not physically present at work but managed to take part into various chats regarding our work. With the help of our wise Scrummaster we now have two short term goals that are simple, well defined, achievable and small.
When reached each short term goal will provide a full CI environment for one productized component. Thus, we are now in a position to plead for one or two sprints focusing only on CI work. In a relatively short time we could achieve a lot that would help us in the future.
This is a very good start. Hopefully we will shortly have a DoTS that would cover all of our components. Then it would be trivial task to estimate when we could be fully CI compliant.
With DoTS we have already received quite a lot of praise for being initiative and proactive. And it has felt good from our perspective too. We are finally taking what is ours, the responsibility of our code base and the freedom with it!
Today we proceeded quite well with our test strategy. We figured out that we have to split our test strategy into two parts.
Majority of our backlog work belongs to the first category. So we did some thinking and figured out that the majority of our testing effort and its automation must go to the version that will be around for longest. This meant that we won’t be automating anything for the version which will drop out of support after the next release. We might automate something for the middle version if the automated tests will work with the latest release with no or very little effort.
With legacy code we will of course focus mainly on integration testing and its automation since it does not make sense to introduce unit testing to source code that can be over 10 years old.
The new code part is another thing altogether. So far we have been using ClearCase as our VCS. Now we have a perfect opportunity (and management approval) to switch to modern DVCS (Mercurial). This enables us to bring in new tools like Maven within the same transformation. Thus, we are finally in a position where we can uilize the latest tools and best practices of agile methods (like TDD, which I brought recently to our unit, but that’s another story) and build a full continuous integration system.
We can finally have a system that can actually clone the repositories, build the software, run unit tests, create and deploy installation packages, run system and integration tests and report the results with one single click (or from a timed execution).
Of course achieving all this takes time and work but this realization alone feels very liberating. It’s like a breath of fresh air after years of smog. We can finally get rid of legacy in-house build systems! 21st century, here we come!
I introduce DoTS as an idea to my team couple of weeks ago. They were receptive and agreed to create one.
So far we have a rough skeleton defined and few short-term goals defined. We had a development backlog already so it will be quite a natural place for all of those new items we will define while reconstructing our defintion of test strategy.
The most important and immediate benefit DoTS will bring us is that with DoTS we are able to satisfy our Product Owner and provide a concrete goal and clear benefits that will emerge from the time invested in our development backlog.
I’m eagerly waiting to see how this takes off and when do we get the first stories into our sprints!
Lately our dear and tall Product Owner wanted us to present a clear and achievable goal for our development backlog. Which makes sense, since even our own efforts to improve our own work needs a plan.
So, I presented my initial thoughts of DoTS to our team. The team, which consists of 8 (including me) very seasoned old dogs, immediately jumped on the topic and found many deficiencies in it. Which made me proud of my team. I got several viewpoints that I hadn’t thought of and we made many improvements and refinements into our initial DoTS.
It is not ready yet but our team is working on it and producing an ultimate goal for ourselves. DoTS has taken off well and I’m very certain that it will improve our daily work and eventually lead to a test environment that is easy to use and which produces test results of our large and complex system in a timely manner. Which, by the way, is not a trivial task since we are working with a very mature and large system (some would call it even legacy ;-).
DoTS has potential so consider defining and adapting one!
Everyone practicing Scrum is familiar with the Definition of Done. It plays quite a crucial role in your daily work. Done is DONE after all :-)
I recently wrote about Continuous Integration and whether it is possible without driving your development with tests (it is not ;-). This leads us to a bigger question. The teams overall test strategy. Does your team have one?
Within the team you have the goal of delivering potentially shippable software after every sprint. Potentially means working and useful as usual. To enable this you have to perform lot of testing, thus manual testing is out of the question (excluding exploratory testing) due to time constraints. That leaves us with test automation.
In order to deliver potentially shippable software the majority of the testing must be automated. And to achieve maximum automation you need a definition of test strategy.
Definition of Test Strategy (aka. DoTS), is simple. Agree how to automate testing on every level, for example:
- Unit testing
- Functional testing
- System/Integration testing
(There are more levels than those, pick whatever relevant levels that fits into your problem domain)
The team needs to arrive at a consensus how they want to approach and achieve test automation. How would your team answer to the following questions and more importantly would everyone else answer alike?
What is a sufficient level of unit testing? How do we write unit tests? Do we use unit test code coverage as a guide? How do we automate the testing of a single complete functionality of a single component (eg. parsing of a xml file)? can we use an existing framework for that or do we need our own? If we need to develop a test framework who takes the responsibility of developing and maintaing it? Does the framework concern others? How do we automate system or integration testing? Do we need extensive scripts in order to perform multiple complex installations on all supported platforms? Can we use existing build tools? How do we cover regression? How do we test user interfaces? How do we maintain tests?
These questions are just the tip of an iceberg. You can probably come up with more but I bet that defining the test strategy for your team will help you to create achievable goals and get you a step closer to comprehensive continuous integration. And thanks to the DoTS all of you will know how to get there :-)
Career, Technology | Jussi Mononen | 
03/05/2011 23:31 | 
Comments (0) 
Subscribe