I’m at EclipseCon this week – a bunch of software engineering misfits talking about software development tools. Just my kind of place! Today I’m delivering a short presentation on how RTC supports Android development by using customization and other baked-in features.
We’re only allowed 20 minutes, so the presentation is a virtual demo that takes you through a portion of the lifecycle of an Android developer. Most of the slides are screenshots that I’ll be talking through. For the sake of clarity, I included a few words on each screenshot (see below).
All screenshots show views in the Eclipse UI.
We start the lifecycle by loading the streams for our projects. Streams contain components, and in this case those components hold the two projects in the Package Explorer. One is JazzDroid, the application being debugged. The other is a set of scripts that help us keep our AVDs and emulator settings consistent across the development team.
Use the RTC screenshot tool in Eclipse to capture the bug in the emulator. We can add arrows and frame areas for emphasis.
A single click on the New Work Item button will create a work item with the screenshot as an attachment. This saves us a couple of boring administrative steps.
The defect shows many common elements you need in any bug report (version, description, etc), the attached screenshot, and some customizations I made for Android such as the platform and API level. There’s also an Environment field where the bug creator can provide the emulator command line options so the developer is better able to recreate the bug.
The developer runs his favorite query, Open assigned to me. We see the defect that was reported, and the developer starts working on it, which changes the state to In Progress.
The RTC Pending Changes view tells us that there are updates to the Approved AVD component. It’s important to keep our AVDs and emulator settings consistent within development and between other organizations like testing. So the developer accepts incoming changes, then execute the new generic AVD script to rebuild the AVD. The script launches the AVD in the emulator using the appropriate arguments, again providing consistency with the Android platform and hardware were testing on.
The developer makes changes to the code, and eventually checks it in. In RTC’s SCM system, checking in only means copying the code to your remote workspace (on the server). It does not share the code with anyone else.
We only check in change sets, which contain one or more files. A change set can be associated to a work item, so the developer associates the change set with the bug he’s working on.
RTC integrates with Git via a set of server-side scripts available on Jazz.net. If the development team choses to use that tool and installs the scripts, the patch can be created from the change set and pushed to the server. Including the work item ID in the description will cause the scripts to create links in the RTC work item and the Git patch page that allow you the navigate between them.
Once all changes are made and tested, the developer delivers the change set to a stream where it can be accessed by other developers and a builds can be performed.
But theres a problem when the developer tries to deliver. RTC’s process enactment for Scrum prevents you from delivering code for a work item that is not planned for an iteration. This is an Agile distinction – you don’t work on backlog items, you work on planned and prioritized items. Of course, in the real world sometimes you work on something that hasn’t been officially prioritized yet.
No problem – we have a set of solutions that the RTC Agile process template gives us. So with a single click we mark the work item as planed for the current iteration, then re-deliver it without problems.
Now that the changes are part of the integration stream, the developer requests a build from RTC. The .apk is built on the build server, and we can see the details of the build in the build log. In this case, we used a simple shell script to perform the build. We could use Ant or another build system entirely.
The build record shows us more details from the build, including a history of successful and unsuccessful builds.
Now that the build has been successful, the developer marks the work item as resolved, which allows the tester to grab the .apk and start testing. We can also see links from the work item to all the work that has been applied to that work item – change sets, builds, etc. We’ve collected a history of our Android development as it applies to this defect.