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.
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.
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.
1. Create 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.
2. Manage application dependencies: avoid release failures by ensuring your testing environments account for version dependencies.
3. Document everything: make sure it’s in a common repository and that it’s easily discoverable.
4. Make approvals visible: you and your team should have agreed upon quality bars that determine what makes it into each environment.
5. Deploy 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.
6. Make 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.
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.
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.
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:
It’s a new way to manage your issues in GitLab. Your issues appear as cards on the Board.
Lists (or columns) represent each step in your development process.
Your 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.
Each 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!
You can drag and drop the lists to organize your Board according to your own workflow:
When you move issues between lists, the label on the issue is automatically updated, though it doesn't show on the issue card.
This 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.
If you drag and drop the card to the list Done, the issue will be automatically closed.
By 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.
Using 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.
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.