For Tuleap 12.10, we’ve got news (to say the least) on Agile Roadmap, GitLab integration, Keyboard navigation… and more. Enjoy!
Roadmap, a Gantt over Scrum dashboard
Roadmap got its load of changes to match how we originally intended to deliver the feature: the ability to automatically draw a Gantt chart on top of the Agile Dashboard without any compromise on Agile values.
We wrote a blog post and to present the feature with full context and a tutorial to show you how to get started with it. Thus, the following section will focus on the changes that landed in 12.10 so if you are new to Tuleap Roadmap we recommend reading the blog post first. You might also want to have a look at 12.9 and 12.8 release notes to get the full picture.
Now, what’s new in 12.10 for Tuleap Roadmap?
- Inherited Timeframe semantic
- Milestones in ribbon
- Multiple trackers on widget
- Hide tasks that are Done
Inherited Timeframe Semantic
Let’s start with the magic sauce of 12.10: inherited Timeframe semantic. What is it exactly? The timeframe semantic is a configurable way to describe the time period of an artifact. It was already possible to define it with a start date and either a duration or end date. Inherited Timeframe semantic offer a third option: pick-up the time period of another artifact.
Let say you have a User Story « US FooBar » that is planned in « Iteration 53 ». Iteration 53 has a Timeframe set with a start date (Monday June 21st) and an end date (Friday July 2nd). With User Story tracker that inherits timeframe from Iteration tracker, « US FooBar » timeframe will be between June 21st and July 2nd.
With this small change, user stories can be displayed on the Roadmap without having to manually manage dates on them. To denote the inherited nature of the time period, the bar is drawn with a dotted line border.
Milestones in Roadmap ribbon
To make it more clear that stories dates are actually the dates of the sprint, it’s now possible to add the sprints (and the iteration and, actually any artifact the define a time period) in the Roadmap ribbon, below the scale.
If the team is using the classical « Release / Sprint » organization, it’s possible to display both.
Multiple trackers on widget
Just like the backlog of the team can be made of various kind of activities (User Stories, bugs, etc), your project is likely to involve a team that is diverse. For instance you might develop a new application but this application is going to be presented at a public show. At this show your sales team is going to demo the app, the will need to train themselves, create demo scenario with the marketing team, etc.
This is typically where Roadmap / Timeline shines so it’s important to be able to represent all kind of activities.
Hide tasks that are Done
Finally, as activities start to grow, you might feel the need to focus on what’s remain to be done. That’s the goal of « Show closed items » switch at the top of the widget.
Watch the demo:
Branch Automation for GitLab Integration
When the product you develop needs to be compliant with strict norms, it’s critical to have strict and irreproachable traceability. From the requirements down to the implementation and the tests, you must prove to the auditors that all the requirements were implemented. You should also prove that none of what you did was « under the radar », that means not related to a specific requirement duly tested.
This is typically done with references, between documents, between artifacts and source code, source code and files delivery, etc. But when doing a lot of tasks and having a lot of references to create, it increases the likelihood to do references wrong (bad copy-paste, mistype a number, etc). It’s even harder when teams are using multiple tools because it might not seem obvious how the links should be created in the first place.
To reduce this risk, we’ve made a bunch of enhancements to our GitLab integration:
- create branch from artifacts,
- reference GitLab branches in artifacts,
- automatically create Merge Request reference when branch contains a reference.
So when you combine all of them, a typical dev workflow looks like:
- Story is broken down into tasks on Tuleap Taskboard.
- A developer goes to the task on Tuleap and click « Create Branch ».
- Branch is created on GitLab, as the branch contains a reference to the task, its automatically linked to the artifact.
- The developer checkout the branch, makes their development and push on GitLab
- When ready the developer creates a Merge Request.
- As the branch is already tracked by Tuleap, it will automatically creates the reference to the Merge Request.
- Merge Request is integrated, the developer goes back to step 2.
So the only action the developer had to do is step 2 and everything is then tracked by Tuleap automatically. Full traceability across tools with ease.
watch the demo:
Define a default branch in Tuleap Git
There is an industry-wide trend to remove usage of word
master in Git mostly in favor of
main. People using GitFlow tend to use
develop as base of their development. Some teams are not doing continuous integration and delivery and must have a way to distinguish the actual mainline for their developments.
In all those cases, each team should be able to define what is the default branch in a given repository. That’s now possible for all git administrators
This setting will be applied on the web UI, that is to say you will browse the default branch by default. It will also apply when cloning the repository. This change is bundle with a protection of the default branch, it’s no longer possible to delete the default branch.
Keyboard navigation in Tuleap Taskboard and Test Management
Keyboard based navigation continues to expand. In Taskboard, most of day to day actions can be done without touching the mouse:
- Navigating between swimlanes & columns
- Moving card from one column to another or change its priority in the current column
- Editing the card and changing the remaining effort
- Toggle closed cards
And it’s even more complete in Test Management:
- Filter test list and navigate between tests
- Mark tests with the appropriate status
- Edit tests, comment, create or link a bug
As for all shortcuts, they are always at one keystroke of you. Type
? on any page and all available shortcuts will be displayed.
Watch the demo:
Tuleap Community Edition official docker image
Tuleap docker images have been there for a while. The first version of enalean/tuleap-aio went live in May 2014, just after dotCloud released the first version of docker without LXC. This image served well for a while but inherited the error we made by discovering the technology. Due to backward compatibility we never had a chance to retrofit the needed change. At some point, this image was then reduce to local tests & demo.
We recently put back the project of having an official image for Community Edition:
- the name was odd to begin with,
- it was no longer possible to update enalean/tuleap-aio to be able to demo the most recent features
- with the recent CentOS drama, we foresee a growing concern of relying on CentOS for community usage.
All this gave birth to tuleap/tuleap-community-edition 🎉
The image no longer embed a database, but comes with all plugins installed and activated by default. This should ease the discovery steps as the first project can be created in less than 5mn.
Bugs and requests
There were 52 bugs fixed and requests implemented during 12.10 release cycle. Bugs and security fixes were already back port on Tuleap Enterprise builds. You will find below a selection of the most notable fixes.