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

Posts tagged “Rational

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…)

Advertisements

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


RSC 2009 – What to expect

I’m not attending the IBM Rational Software Conference (what used to be RSDC, RUC etc. etc.) this year however since it started today for partners and tomorrow for delegates so I thought I’d cast my opinion on what to expect this year. Of course I could be wrong since it’s just assumption but I suspect the main themes will be:

A vision of one notion of process for all Rational tools, made explicit in the relevant tools, surfaced through process rules and defined in practice libraries allowing easily composable and customisable processes based on the Jazz Process architectural elements.

So to tie  it all together the Process Library (which of course is practice based probably driven by Rational Asset Manager) feeds definition of processes in RMC, which is measured by MCIF and delivered by the Rational Software Development Platform. So what does that really mean:

Rational Team Concert 2 beta – because it’s a lot better than RTC 1 which was pretty good to begin with!

Rational Tara –  a Jazz based PPM (Project Portfolio Management) tool. Think MS Project by IBM on Jazz with better Resource Management stuff. It’s part of the replacement suite for Rational Portfolio Manager (RPM).  Should be interesting to see how it ties into the other products (inc. some of the Telelogic ones). I expect this one to be big news – it should be. Gantts, bubble charts, resource utilisation views, agile dashboards etc. will abound. (Now known as Focal Point for Project Management)

Rational Insight – used to be codenamed Vega and is a data warehousing and RTL solution on top of Jazz. Cross project reporting goodness. Of course I’m sure there will also be integration through to the “classic” rational tools. Interestingly I read a bit of blurb recently from somwhere that referred to their old tools as the “classic rational toolset” I wonder if they borrowed that from me 🙂

MCIF – Measured Capability Improvement Framework – It’s been around for a while but with more emphasis from IBM now on practice based process the story between a more practice orientated Rational Method Composer, Health Assessment tools and Self Check tools is a bit tighter.

Telelogic – I expect there to be some announcements about the integration of the Rational and Telelogic brands. Especially around FocalPoint.

I’d also expect some stuff on other Jazz based tools like Requirements Composer, Quality Manager, Ensemble, Governor and stuff like that.

As I said due to other commitments I’m not there myself, but if you are there then please stop by the Ivar Jacobson International stand in the Exhibit Hall downstairs when they let you in. Grab a free beer and talk to my colleagues about how to achieve tangible process improvement with the use of effective practices in a proven framework. Also talk to them about achieving “Agile for Grown Ups” (TM of the MacDaddy) in your organisation. Ivar, Ian Spence, Kurt Bittner are all speaking at the conference and a bunch of other IJIers will be there so go along and say hi.

And ask for a free bag, they’re great for carrying around your exhibit hall swag 🙂


How to avoid Fragile Agile, Flexibility in Context

A presentation I gave at the UK RUG Annual Meeting on what can make agile development fragile and how to avoid that fragility.

Unfortunately animations don’t work and slideshare’s screwed up the agenda slides but you can still follow it 🙂


Rational, Telelogic and Jazz roadmap

There’s a lot of interest in the IBM Rational space about the future roadmap of Telelogic products like DOORS and Rational Requisite Pro and some murmurings of new shiny future things like Tara, Vega, MCIF, FocalPoint, Rational Change Management etc. etc.

I’m sure as the year continues we’ll learn a lot more about these things (or at least be able to talk about what we already know under NDA as IBM Rational and Telelogic are bound to make some statements and showcase the future at RSDC09. This year the RSDC is combined with the Telelogic User Conference (Innovation) which is a public sign of how integrated IBM want the Rational and Telelogic brands to become in the future.

All of this is very important for existing Telelogic and Rational customers, as well as people interested in Jazz or using Jazz. So I noticed a presentation from RSDC in Italy that covers some high level information on the joint product roadmap: