background
I've been a religious user for github/zenhub for quite a while. We recently moved our repos to gitlab for many reasons, including free pipelines, security, more flexible groups etc.
Problem
Zenhub is a greasemonkey app that's added to github, one of its features is the scrumboard that's similar to gitlab's native issue board. One of the amazing things about zenhub scrumboard is that it allows you to put many repos on the same board (I recall jira had the same thing).
question
Is there a way to do this on gitlab?
Beside a third-party like kanban.leanlabs.io, recent GitLab releases do integrate a more sophisticated issue management.
See "Announcing The GitLab Issue Board " (presented here)
But it might be limited to only the current repo.
Note that with GitLab 13.6 (November 2020), this is no longer limited to a repository:
Group-level management of project integrations
In GitLab 13.3, we added the ability to enable an integration across an entire instance. With GitLab 13.6, that feature is being expanded to allow integrations to be managed at the group level as well!
Group owners can now add an integration to a group, and that integration will be inherited by all projects under that group. This has the potential for saving massive amounts of time, as many organizations have specific integrations that they want rolled out to every project they create.
A great example of this is using our Jira integration. If you’re using Jira, it’s almost always across the whole company. Some of these companies have thousands of projects and therefore had to configure each and every one of those integrations individually.
With group-level management of project integrations, you can add the integration at each parent group, reducing the amount of configuration required by orders of magnitude!
Read more in our announcement on the GitLab blog.
See Documentation and Epic.
In GitLab issues and merge requests within a group display a collection of issues and merge requests from all projects below them.
And they also have an Issue Board available, which aggregates the issues from the projects within the given group. This is currently not reflected in the documentation, and could be well worth a Pull Request in doc/user/group/index.md and doc/user/project/issue_board.md.
Using this together with group labels and milestones, which also span across all subprojects, you can create the desired board view.
I do use github/zenhub in the past. https://gitboard.co is the zenhub alternative for gitlab. Which shows all your issue and merge request in one simple dashboard across multiple projects.
Related
I'd like to cross-check the vulnerabilities covered by GitHub's CodeQL service and OWASP Top Ten Web Application Security Risks so that I know where the gaps are.
I can't find a list of vulnerabilities covered by CodeQL. Does GitHub publish the list of rules?
The source code of the CodeQL queries is available in the GitHub repository. The documentation also lists the existing queries:
CodeQL query help
CodeQL CWE coverage
However, which queries (or rather query suites) are run as part of GitHub workflows depends on the configuration of the workflow.
I am using Team Foundation Server by Microsoft. I will probably migrate from one account(server) to another account, and I would like to preserve following things:
source control of files
users
scrum sprints (epics, backlogs, tasks, bugs)
builds
Azure subscription:
move all web services
move all sql databases
How can I approach this? Is this manual work one by one, or can I use some tool for migration?
There is a TFS migration tool / body of knowledge that will help you thought most of the items you list under TFS. You can find it here. This should be fairly straight forward unless you have customised process templates which then create a few more headaches. Moving Builds may be tricky, there is a recently released article on scripting builds with YAML which may be of use.
For the Azure components, you can:
Move databases between subscriptions
and I believe you can do similar for WebApps/Services. You can also move subscriptions using PowerShell.
Product , catalogs etc both staged and online we have in Hybris...If we want show online the staged one we do synchronization but why we need staged products or catalogs?
Modifications of - Content, Product, Media,... - are made first in the staged catalog.
When changes/modifications are tested/approved and you are satisfied then you publish them to be available online to your users by synchronizing staged catalog to the online catalog.
Imagine if you have one single catalog, your users will be able to see unapproved and untested changes immediately, that's will increase the amount of risks and errors significantly.
You allow the merch team to upload the proper visual, modify product texts etc... Then they can also test product pages with various device without any impact on the online website (online catalog).
It also allows to prepare seasonal catalog. For exemple you're in summer and you can start to work on the online version to be deployed on winter.
Stage catalog is the one on which you work - change the data, etc. This catalog is not displayed in the storefornt.
Online catalog is used in the storefront and should not be manually edited.
Usually there is synchronization between Stage and Online versions so that when the changes are approved for showing to the customers the synchronization is triggered and the products are available in the Online catalog (which implies storefront visibility).
I'm using Gitlab and I've several projects.
project1;
project2;
project3;
Is it possible to have a common Wiki for these projects?
Every wiki is linked to a project, but there is a workaround:
Go to Settings → Services → External Wiki for your 2nd and 3rd projects and set External wiki URL to the URL of your first project wiki:
Or you can host your own wiki, for example, gollum on your server for the same purpose.
Is it possible to have a common Wiki for these projects?
Yes: (October 2020, 4 years later)
GitLab 13.5 proposes:
Group wikis
For many teams, using GitLab wikis for planning and documentation is a critical part of their workflow. Wikis are so popular that they get over a million views each month on GitLab.com. Despite this popularity, teams have struggled with the limitation that wikis were only available at the project level.
Teams working on multiple projects needed to create separate wikis for each repository, leading to a fragmented experience.
In Gitlab 13.5, we are so excited to bring you group wikis!
With 680 upvotes this was the most upvoted feature in the entire GitLab backlog. While highly requested, making a large project-only feature like wikis available at the group level has been a non-trivial operation. We’ve worked tirelessly over the past year to make it happen and now we can’t wait to get it in your hands and hear your feedback.
Group-level wikis open up tons of possibilities to keep your information at a higher level and accessible to a broader set of people. A few examples of what you can put in your group wikis include team-specific information, coding style guides, and designs for your brand or your company.
We know a lot of folks have been looking forward to this feature and shared their input pre-release. We hope all of you will continue to weigh in now that group wikis are available and we’ve opened up a dedicated issue for your feedback.
See Documentation and Issue.
Are there any guidelines and best practices for organizing Visual Studio Team Services for a new cloud app? I'm planning on creating a WebAPI solution for REST services, a Xamarin Forms solution for mobile client, an MVC solution for web, and finally SQL scripts. Ideally, I'd like to account for future apps with their own source code.
Dev
App1
WebAPI
XamarinForms
MVC
SQL
App2
...
...
Test
Prod
Another approach is to create a project per App
App1
Dev
WebAPI
XamarinForms
MVC
SQL
Test
...
Prod
...
App2
...
I have also seen people put everything into a single giant project under a single collection. So, instead of creating Dev, Test, Prod projects in the first tree, we'd create them as folders. Same with the second tree. Why would I not want to create multiple team projects?
I'm not a TFS expert, but I'd like to get started on the right foot.
P.S. I've seen a few similar questions on SO but did not think they answered my question, especially the part about not creating team projects.
Visual Studio Team Services (and Team Foundation Server on-premises) support the notion of Team Project Collections, Team Projects and Teams.
A TPC is the highest degree of separation. Currently, you get one DefaultCollection on VSTS. Within this collection you create separate Team Projects. Within a Team Project you have one or multiple Teams.
The current best practices state that a single Team Project is the easiest to work with. In short, this allows you to more easily share code, work items and other assets while still having separate backlogs and code repositories.
For a more detailed explanation see a couple of blogs on this subject such as:
Why You Should use a Single (Giant) TFS Team Project
One Team Project to rule them all
Many Git Repositories, but one Team Project to rule them all
In your scenario, I would absolutely go with one Team Project and then multiple Teams for each separate application. In the top level team you can then schedule Epics and Features and distribute these to the implementation teams.
If I started such a project today, I would also choose Git for Source Control. Git and TFVC are both supported and TFVC is going nowhere. Git however does have some advantages that I think are very attractive.
Regarding your folder structure. If App1 and App2 need to be released together, they should sit in a shared branch. If they can be released separately, they should have their own branch.
The ALM Rangers have a great document on Version Control that explains different Branching models. This is freely available on CodePlex.