Somewhere in the overlap between software development, process improvement and psychology

Posts tagged “build

Process vs. Tools

What’s more important: Process or tools?

I’ve sat through numerous arguments with people trying to work out whether process or tools are more important to their software development effort. The arguments go along the lines of:

Process Geek: Tools are just the things you use to do the process, the value is in the process. Let’s do a process first roll out.

Tools Geek: Tools are the things people actually use. Process is academic and is constrained by the tool features anyway. Let’s do a tools based roll out.

Sadly both of these are real life quotes from people I’ve worked around in the past. I won’t embarrass them by naming them because they’re both really wrong. For me the real value is not in the tools or the process but in the people. Process and tools are something that you add if the people need them.

Minimal Tooling

For me the best planning tool is a whiteboard. The best architecture and design tool is also a whiteboard. I like to capture some info about what I’m doing and how close I am to achieving my goals, some really simple measures. The best tool for that is probably Excel, despite my love of Open Source. Other than that I need to manage some lists of things like requirements (stories/use cases whatever), defects and whatever other bits the team thinks are important. They might fit on a whiteboard but typically we want to have some attributes on them, be able to sort them and link them. The one downside of a white board is the lack of drag and drop. I’ve used a few different types of smart board and active touch screens but none of them have really given me the smooth experience I want.

The one bit of tooling I really need is my IDE + SCM + Continuous Integration.

Minimal Process

This is potentially a can of worms if I go into things like process kernels and ideological arguments about different agile approaches and practice collections. There’s no such thing as a process silver bullet so for me though it’s all about the team and being effective. Teams need to:

  • Have Clear Obligations
  • Have Clear Business Priorities
  • Seize their autonomy
  • Have the relevant technical skills and resource availability
  • Be active in actually doing their work (seems obvious but it’s something a lot of processes seem to hinder rather than help)
  • Demonstrate visible progress (via working software not a tracking gantt chart)
  • Continuously improve themselves (because no way of working is perfect)

This list based on the 7 Habits of Agile Teams by Roly Stimson

So why go more complicated?

Unfortunately life is rarely simple. Many teams work in complex environments where a number of factors might make them choose to need more than this kind of minimal set including things like physical distribution; audit, regulatory or security constraints; cross-team interaction in system of systems environments, more people etc.

When faced with increased complexity it might be appropriate to add more powerful tooling or development practices. The more people involved in a project the harder it is to herd all of those socially complex cats into working together.

This is why ALM suites exist ranging from plugging together some open source bits like git, SimpleGit, jenkins, agilefant, bugzilla etc. to commercial vendor products like IBM Rational RTC (which does agile planning, work item management, scm and build in one tool) and other IBM Rational Jazz tools – it’s worth noting that you can also get RTC for free for just 10 users or for academic/research use on jazzhub.

Alternatively there’s Microsoft TFS for source control, work item tracking etc. tying together existing Microsoft stuff like MS Office, Visual Studio and sharepoint if you’re a more Microsoft focussed development house.

Of course you can also mix and match this stuff to a greater or lesser degree with various integrations. No toolset is a silver bullet however and each have their own problems.

So what’s my point?

My point is that process and tools need to reinforce each other, that both should be selected based on the needs of the team and the environment the team has to operate in. In the process vs. tools argument both lose out to the people. People in a development organisation create value, they just use tools and process to do it.

Advertisements

How to do maven releases with Jazz SCM

I’ve previously blogged on structuring maven multi-module projects to work well with m2, eclipse and Jazz SCM. In this post I’m going to write about how to do releases because it’s not as straight forward as you might hope and expect. This blog is explicitly about using maven 2.2 and IBM Rational Team Concert 3.0.1.2 although it will apply to various other previous versions. Later versions of RTC should (I hope) alleviate some of the problems and the Jazz SCM Maaven plugin is being actively work on.

Overview

During development or maven projects we start with a label such as 1.0.0-SNAPSHOT which reflects the current development build. Over time the development snapshot might be occasionally pushed to a maven repository as a “snapshot release”  if it’s roughly stable so that dependant teams can get the dev version if they really want it. In time development gets stable enough to release the definitive 1.0.0 so the -SNAPSHOT is stripped from the label and the version is pushed to the repository as a proper “release” for other teams to depend on. At this point a new number is selected and development continues on the new label such as 1.0.1-SNAPSHOT which might be occasionally pushed etc.

Diagram showing how releases and version numbers work with maven

The problem

This process works pretty smoothly in a lot of contexts as the release is done by issuing a command line as simple as mvn release and maven’s smart enough to work out the rest. The problem comes in the context of Jazz SCM for a couple of reasons:

  1. The Jazz Maven SCM plugin is still in early development so doesn’t do everything well and some things not at all
  2. The Jazz Maven SCM plugin incompatible with the maven release plugin because it requires the pom scm tags to be written in a way that the release plugin can’t read
  3. The jazz scm plugin insists on outputting your password in cleartext all over the logs so you can’t do it as part of an RTC build without exposing the build user password (which depending on your organisation might not matter or could be a huge deal)
  4. Both maven and rtc use the word snapshot for different purposes and other terms like “baseline” and “tag” are synonymous

The solution

Write a little script to work around the problems with the following requirements:

  • All published version numbers in the maven repository must be reflected by RTC scm snapshots
  • The process of releasing is simple to use

To make this work I’m actually dumping the use of the Jazz Maven SCM plugin as it’s not yet developed enough to be useful. Instead since every build happens in RTC occurs in a snapshot here’s the process:

  1. Green Build in RTC (optionally promoted to RTC Release) with a known snapshot name e.g. v1.0.1 release
  2. Integrator/Releaser/Committer/Nominated dev runs custom mvn-release script on their local machine
  3. Sits back and watches, feels good

Here’s the pseudo-code for how to do it all. One of my clients is developing this currently and I’m reasonably optimistic that they might open source (or allow me to) the full script. However if you’ve got a bash monkey working for you it shouldn’t be hard to develop this up pretty quickly.

Currently this process needs some parameters which could be passed in or the user could be prompted. I prefer to pass in and prompt so that the script can be invoked from a remote process (like a build server) passing in properties or can be interactive if a user invokes it. Parameters required at least somewhere along the way are:

  • rtc user name and password
  • is this a snapshot release or proper release
  • rtc build snapshot
  • new version number to base label (if doing a proper release)

CURRENT_VERSION = getCurrentVersion(pom.xml) //1.0.0-SNAPSHOT

//If just doing a basic snapshot release
scm create snapshot "CURRENT_VERSION"
scm checkin & deliver
mvn deploy

//If doing a full release
PROJECT_NAME = getCurrentProjectName() //basename of current directory
NEW_WKS_NAME = create new rtc workspace in /tmp/rtc/workspace/RTC_SNAPSHOT_NAME/
load temp workspace with contents of RTC_SNAPSHOT_NAME
cd /tmp/rtc/workspace/RTC_SNAPSHOT_NAME/PROJECT_NAME
//Generate Release
RELEASE_VERSION = StripSnapshot(CURRENT_VERSION) //1.0.0
mvn versions:set -DnewVersion="RELEASE_VERSION"
scm create snapshot "RELEASE_VERSION Release"
scm checkin and deliver
mvn deploy

//Generate new development starting point
NEW_VERSION = AskUser(); //1.0.1-SNAPSHOT
mvn versions:set -DnewVersion="NEW_VERSION"
scm create snapshot "NEW_VERSION Initial baseline"
scm checkin and deliver
//don't do a mvn deploy as that would be the user choosing to run this script choosing the snapshot-release option

//Tidy up
scm delete workspace NEW_WKS_NAME

The advantage of running this script creating a temporary local workspace and running from there is that you can do this from the command line without closing eclipse (or invoke from Eclipse as an external tool configuration). Also it isolates the release process from any possible local changes in the /Releaser/Committer/Nominated dev’s workspace.

Until the Maven SCM plugin comes of age I hope this helps.


Advanced RTC SCM Streaming – Part 3 Component reuse

Basic usage of RTC Jazz SCM is easy enough but there’s what about more advanced usage? Using streams to isolate development from integration? Cross-project component reuse? Parallel branched development? Integration Streams aligned to Definitions of Done? This is the guide for that stuff.

This blog is in three parts:

  1. Development, Integration and Release Streams
  2. Streams for parallel branched development
  3. Streams for component reuse

Part 1 also covers the introduction and overall conclusions

Working with components across multiple RTC projects can present a bit of a challenge. It’s simple enough to create a stream with any baseline of any component in your repository but dealing with changes to those common components is not simple or obvious, especially if you need different visibility controls and access rights for different teams on different components.

(more…)


Advanced RTC SCM Streaming – Part 2 Parallel branched development

Basic usage of RTC Jazz SCM is easy enough but there’s what about more advanced usage? Using streams to isolate development from integration? Cross-project component reuse? Parallel branched development? Integration Streams aligned to Definitions of Done? This is the guide for that stuff.

This blog is in three parts:

  1. Development, Integration and Release Streams
  2. Streams for parallel branched development
  3. Streams for component reuse

Part 1 also covers the introduction and overall conclusions

Change set based SCM systems like git (SimpleGit)and RTC do away with the need for a lot of branching. You don’t need to branch to get developer isolation, to gather file changes together to understand them as an atomic set of changes related to a bit of work or to manage concurrent development of the same files on a small scale. You get all of that for free by using change sets. Developers are always in their own private personal branch separated from the rest of the team but unified by a common stream or repository. However sometimes it’s still appropriate to branch, this blog covers some of the situations when it’s appropriate and how to do it effectively in RTC Jazz SCM.

(more…)


Advanced RTC SCM Streaming – Part 1 Development, Integration and Release Streams

Basic usage of RTC Jazz SCM is easy enough but there’s what about more advanced usage? Using streams to isolate development from integration? Cross-project component reuse? Parallel branched development? Integration Streams aligned to Definitions of Done? This is the guide for that stuff.

This blog is in three parts:

  1. Development, Integration and Release Streams
  2. Streams for parallel branched development
  3. Streams for component reuse

Part 1 also covers the introduction and overall conclusions

(more…)


Working with Maven multi-module projects in RTC Jazz SCM with m2

I’ve been working with Maven projects with m2 for a while in RTC Jazz SCM so thought I’d post some notes. For reference this post covers using RTC v3.x things may change in the future. If you’re not using m2 then I’d suggest you read this blog by Philippe Krief.

First of all it’s important to understand that RTC v3 has limited support for Maven. You can setup a build definition which can call a maven goal (such as a local install) easily enough but that’s about it. The RTC build mechanism is basically a cron job with a nice web (like Hudson/Jenkins without the plugins) and Eclipse front end, it doesn’t have a deep understanding of Maven.

The whole point of Maven over Ant is that it does a lot by convention rather than specification, however in most advanced Maven project I’ve seen pom files are as big as equivalent Ant + Ivy files. Regardless I still think Maven with the excellent Sonatype Nexus is awesome (although I also like the structured bash/batch like nature of Ant as well).

Most serious Maven projects are multi-module. This is because component based development is a good thing (shameless employer plug, but it’s true, it is a good thing). Most (tending to all) multi-module projects have the following structure where “O” is a folder and “-” is a file, considering a hypothetical ProductX:

– pom.xml (the parent pom for the master/uber/product build, lists child modules)

– various files at the root of ProductX

O ModuleA

– pom.xml (for ModuleA)

– various ModuleA root files

O various ModuleA folders of stuff (such as src)

O Module B

– pom.xml (for ModuleB)

– various ModuleB root files

O various ModuleB folders of stuff

If you want to work with this stuff in RTC Jazz SCM then you need to balance the constraints of Maven m2, RTC and Eclipse. If you’re considering doing this then you’ll probably be considering moving existing Maven projects to RTC, in which case you may find a previous blog on a manual migration script useful. The only edit to this I make for Maven is to separately import the parent from the children if flattening the structure (although in most cases I wouldn’t recommend flattening).

The constraints playing against each other are:

  • Maven and plugins expect sub-modules to be in child directories as in the tree above
  • RTC doesn’t allow both an Eclipse project and root files to be at the root of a component
  • The simple case of Eclipse and RTC SCM interacting during a load from the server restricts Eclipse to only seeing projects which are represented as folders at the root of the local Eclipse workspace containing .project files.
  • Eclipse doesn’t really support parent and child projects.

I’ve found there are a number of approaches, none are perfect:

1. Flatten the structure (my opinion the worst option)

You can edit the parent pom.xml to reference the sub-modules as ../ModuleA etc. although the Maven release plugin (amongst others) don’t play well with this. Also, and somewhat fundamentally, you shouldn’t have to restructure your code based on your SCM tool.

2. Only load the relevant bits (my opinion is it’s sometimes ok)

You could just load the child modules you’re currently working on and then unload (remember to delete local files or you hit a bug) and then reload the parent when you want to do a “big” parent build. Frankly this is unacceptable from a developers perspective and will fail anyway if there’s a dependency on the parent from the children. Although in theory this may be frowned upon it’s quite common and so needs supporting by the scm tool.

3. Load then import, with auto-refresh (my preferred option)

This one is going to be more than one paragraph….

Prediction fulfilled ;p Anyway… Currently your developers may be used to a scm system where they load/copy/access files from the scm system on the local filesystem and then do an Eclipse -> Import Existing Maven projects to get all of the various goodies.

If you import the multi-module project as above but with a root folder (as an eclipse project) so it has the following structure:

O Product X

.project

– pom.xml modules)

– various files at the root of ProductX

O ModuleA

– pom.xml (for ModuleA)

– various ModuleA root files

O various ModuleA folders of stuff

O Module B

– pom.xml (for ModuleB)

– various ModuleB root files

O various ModuleB folders of stuff

Then when you do a load from Jazz SCM you’ll get in the Eclipse Project Explorer (or equivalent) ProductX correctly detected as a Maven project (or an Eclipse project with a Maven nature for the pedantic amongst you).

You can then do a normal Eclipse -> Import Existing Maven Projects based on your workspace/ProductX/… (taking care not to select “Copy projects into workspace”) You’ll then get in Project Explorer (or whatever):

ProductX (info about rtc scm links)

ModuleA

ModuleB

In this view ModuleA and ModuleB exist in two places: as projects referenced in the workspace but apparently outside of RTC SCM control; as a folder structure under ProductX/ModuleA and ProductX/ModuleB.

This has the following advantages:

  • Cross-project dependencies resolve
  • You can run the parent/uber pom goals and the child pom goals without reloading anything
  • You can shift focus between the child-modules and parent structure without reloading anything

If you edit files in ModuleA and ModuleB under the folder hierarchy of ProductX then Pending Changes will keep track in the normal way but if you edit a file under the apparent “root level” ModuleA and ModuleB then Pending Changes won’t unless you do a “deep refresh”.

Alternatively just go to Eclipse -> Window -> Preferences ->  General -> Workspaces -> Refresh automatically (er… I think, I’m doing this from memory, hence the lack of screenshots). You can then add “edit files tracked by Pending Changes at either Product or child module level” to the advantages above.

So this option sounds great so far, what are the downsides?

This solution maintains the hierarchical structure between ProductX and it’s child modules and as such constrains everything from ProductX downwards to be in the same Jazz SCM component as eclipse projects can only be seen (without far too much fiddling) if they’re root folders in components. This may not seem like such a big deal but components are the lowest level of baseline (or label) in Jazz SCM. In a tightly coupled cohesive single architecture this might not be a problem but if you want to reuse any of these modules (at a code level) or have a separate ownership it will be a problem. It’s also very common to have dependencies from child modules to parent projects (which may initially seem to resolve if they’re in the local ~/.m2 repository).

Having said that source code dependencies between components lead to brittle architectures, binary dependencies are far superior, and made much easier by the use of things like Ivy/Maven and Nexus.

Other considerations

The point above above binary vs. code dependencies can be argued until the cows come home and go out again (an extended metaphor), especially if you consider project/product/team/release boundaries. I’m not going to pretend to answer those with an academic silver bullet here, the important thing I hope you take away from this blog is that there are pros and cons to all of these approaches, balancing those with the needs of your team/architecture/project/organisation are not easy. Shameless plug: Give me a call if you need help

Eclipse refactoring isn’t dealt with well by Jazz SCM, especially between Eclipse projects in and “out” of source control (advocated by option 3 above). Expect a lot of “remove/add” combinations if you are doing anything more than a trivial set of file changes. This is also a problem for the ClearCase <-> RTC automatic synchroniser developed by the excellent Samecs however I know that I, others and Samecs are pushing for improvements on this from IBM.

This post has been very scm focussed but what about build and release? The RTC build engine understands maven to a limited degree and can easily invoke maven builds for information on integating the maven release process see How to do maven releases with Jazz SCM


The Kung Fu of Software Engineering

I’ve been studying both kung fu and software engineering for many years. I’ve come to realise that they are very similar and that kung fu is a pretty good metaphor for software engineering.

Done right it looks easy, but it’s not

When you watch kung fu in movies, or martial arts in general it makes sense logically, it looks sensible. Attackers punch in one direction and defenders block in another. Sometimes there are tricks and special moves but an observer can see the logic in them, and they are feasible if clever – they are complicated, not complex. However when you actually try and do these moves you find it’s not so simple. It’s not easy to react the right way under pressure when you’ve not done it before. You need to learn muscle memory, improve your fitness, work on your reactions and internalise sometimes counter-intuitive techniques. When you really do it well you use very little energy to do something that looks easy and it becomes easy but other people can’t get it just by watching you.

Both software engineering and kung fu are deceptively difficult, with hidden complexities and complex emergent behaviour. I think it was Grady Booch who said (although I couldn’t find the quote so any mistake is mine) “Software development has, is and always will be, inherently complex”.

Complexity built from simple small techniques

In many kung fu styles you learn basic small movements in repetition, often called “form” in martial arts, Sil Nim Tao (generally referred to as Siu Nim Tao in Wing Chun kung fu, the RUP of kung fu) is translated as “little idea form”. Learning this form we learn all of the basic movements and stances that set up the body positions required to get the mechanical advantage in a given situation. Each individual movement tends to be very, very simple.

This kind of information and learning is analogous to the basic software engineering knowledge that we give people. We teach them how to write in a language, idioms, patterns, standard architectures, frameworks, build technologies, iterative patterns etc.

However knowing which techniques apply in which situations, which play well with others and how to put them all together is another level of expertise based on experience. Teaching someone the basics does not make them a master. Software engineering, like kung fu is something you should never stop practising and learning.

It gets more complex when you add more people

Defending yourself from one attacker is a whole different ball game than defending yourself from two attackers. Defending yourself from a group of attackers breaks down the whole mixed metaphor of ballgames, sports and anything else in the vicinity. The complexity of the action increases significantly as you add more people, it’s not just a linear relationship. As more and more people are involved there are emergent behaviours that can’t be predicted from the beginning.

This is true of any activity that multiple people take part in, especially complex activities. In kung fu it means you have multiple attacks, more energy in your attackers which means once you’re tired you’re in trouble. In software it means you have multiple people doing things at the same time with subtly or radically different ideas on what should be done and the best way to do it.

The only ways to reduce this complexity in software engineering are to go up or down. We can either abstract away from the complexity moving to higher level technologies where possible (sacrificing fine control typically) although such abstraction tends to bring it’s own complexities or we can dive down and educate the team (in the broadest sense) on the complexities to try and reach a common understanding.

No plan survives contact with the enemy

Trying to plan in detail all of the possible interactions of a kung fu fight, even against a known assailant is about as pointless as trying to plan all of the details of a software project. There is too much uncertainty, too much complexity and too much emergent behaviour. Above all there is too much change. In both kung fu and software engineering we need to remain agile and responsive to change. Change in the environment, the different things being thrown at us and our own actions.

There’s no magical solution

We’re not in the Matrix, we can’t download kung fu skills into our heads in seconds. Or software engineering skills. These things take years to learn, will be slightly different for every individual as they tailor the standard wisdom to their particular individual skills and style.

There’s a lot to learn. Personally I sometimes work as a software development coach helping people structure and plan their work from a business, planning and architecture perspective mixing in  SCM & build techniques, tooling, requirements management, agile and iterative project management, portfolio and business management. In many ways these kind of things, and others similar to them, can be thought of as different styles of martial art. Just because you’re good at one of them doesn’t mean that you’re good at another, or the next new one that comes along. Of course a certain aptitude helps, and knowledge of one certainly makes others easier to learn but “experts in everything” are few are far between.

We can’t all be Bruce Lee, Jackie Chan or Jet Li but we get a choice about where we are on the spectrum between being a master and an armchair expert sitting on the sofa watching others do it.

Finally

I believe that there’s an exact art and subtle science to both martial arts and software engineering. We need to practice these skills, we need to be continually learning and improving. We need to learn from other styles and experienced practitioners.

“Kung Fu” is actually translated to “achievement through great effort”

If you’re in the Cheltenham, UK area come and do some kung fu with me at Chi Wai Black Belt Academy.

I’ll leave you to make your own Chuck Norris software jokes…