Software is eating the world. Reducing the time between having an idea and having the code in production
is a great competitive advantage. Planning what to do next is an essential part of that process. Today we
introduce our Issue Board that will make it faster to plan issues. It is an integrated part of GitLab, ensuring
you don't have to switch tools to get things done.
Release management isn’t perfect
Understanding your team’s challenges is the first step to solving them.
Speaking from our own experiences shipping GitLab, some of the release
challenges we face are:
Planning: we release on the 22nd of every month. To hit our release goal,
we have to be incredibly diligent about what we forecast for each release.
Communication: with a growing team consisting of 24 developers, 6 frontend
engineers, and 5 UX designers, it has become increasingly more important to
ensure the full team has visibility into the overall release process.
What the experts had to say
Obviously, we’re not “the experts.” But we’ve summarized their feedback.
The International Journal of Computer Applications 2013 study has
great insights into effective release management processes.
a single source of truth: eliminate the natural differences that
occur with large teams working in different time zones, running different
processes, and using different tools.
application dependencies: avoid release failures by ensuring your
testing environments account for version dependencies.
everything: make sure it’s in a common repository and that it’s
approvals visible: you and your team should have agreed upon quality
bars that determine what makes it into each environment.
consistently across environments: standardize your build, test,
and deploy process by automating as much as you can. The goal is to
remove error and unpredictability.
the release plan easy to consume: we’re lumping all the
P's (planning, people, process, and policy) together. They all boil up to
the same key ideas. Policies and plans should be centralized. Ownership must
be clear. Finally, a change in plans needs to be visible to the full team.
GitLab: From idea to production
That list is easier said than done. But it’s where we are all headed.
Modern development teams are optimizing for speed without sacrificing quality.
They are moving away from older process-driven development styles like Waterfall,
Scrum, and Agile and towards continuous delivery and deployment. To
support modern development practices, GitLab has everything you need to get
from idea to production faster.
There are 10 steps from idea to production in the modern development lifecycle.
- Chat conversation → Mattermost ships with GitLab
- Issue creation → GitLab Issues
- Planning board → GitLab Issue Board
- IDE → Koding + GitLab Integration
- Version control → GitLab Repositories
- Continuous Integration → GitLab CI and GitLab Container Registry
- Code review → GitLab Merge Requests
- Continuous Delivery → GitLab Deploy
- Chatops → We're planning to ship Cog
- Feedback → We plan to ship with Cycle Analytics
The 10 steps of the modern development lifecycle will be included directly in
GitLab in the coming months. Today we are announcing the GitLab Issue Board,
a software project management tool used to plan, organize, and visualize a team’s
feature or product release process.
Closer look at the GitLab Issue Board
The Issue Board builds on GitLab’s existing issue tracking functionality and now
offers teams the ability project manage their release and deployment process. This
is the first iteration of our Issue Board. Here are a few things you should know about:
The GitLab Issue Board
a new way to manage your issues in GitLab. Your issues appear as cards on the Board.
(or columns) represent each step in your development process.
lists are based on your Labels. Which means it works out of the box with your existing issues.
So if you’ve already labeled things with “Development” and “Production”, the corresponding issues will
appear in the lists as you create them.
Issue Board starts with two lists: Backlog and Done. The Backlog will hold all the issues in
your project which don't have any label assigned to a list. Once you label an issue, and create a list for that
label, it will be automatically moved from Backlog to the corresponding list. You can create unlimited lists!
can drag and drop the lists to organize your Board according to your own workflow:
you move issues between lists, the label on the issue is automatically updated, though it doesn't show on the issue card.
new label is displayed in the Issue Tracker as well as on the issue itself. So, even if someone on
your team isn’t checking the Issue Board, they’ll still have a record of what step an issue is on.
you drag and drop the card to the list Done, the issue will be automatically closed.
adding new lists, you can create workflows. For example, you can create a list
based on the label of “Frontend” and one for “Backend”. A designer can start working on
an issue by dragging it from Backlog to “Frontend”. That way, everyone knows,
this issue is now being worked on by the frontend engineers.
Then, once they’re done, all they have to do is drag it over to the next list, Backend,
where a backend developer can eventually pick it up. Once they’re done, they move it to
the list Done, to close the issue.
Read through the Issue Board documentation to know everything you can do with it.
GitLab’s existing Label functionality also means that you’ll have all the same
filtering and sorting abilities you see across the rest of the product.
Join our webcast
On September 1st, we’ll be hosting a webinar to discuss and demo the Issue Board and all of the other
great features in GitLab 8.11. Register here.