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.
Related
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.
As I'm in development on my 2nd and 3rd kentico sites, we're looking at code management. Our ideal solution is a single Kentico Solution, with individual CMS folders.
In theory this should be fine, but would there be any potential issues, especially regarding versioning? Right now, I have one site on 9 hotfix 5, and the other two on 9 hotfix 30.
There would be a problem with applying hotfixes and upgrades. They both count on the fact that the web project is in a folder called CMS... So you would introduce some manual steps in those processes. Conclusion - don't do that.
I certainly agree with #rocky. I'd question what advantages you expect from this scenario? I assume the 3 sites are entirely independent of each other (don't share a database) so keep them as separate Kentico solutions. They're separate applications so why share a solution file? This'll make your life so much easier. A solution should only contain multiple applications if they're intrinsically linked.
If it's because you have custom code that you'd like to share between the instances, best to move that code into custom assemblies and share those in your various solutions. If necessary your separate solutions could include the same files as per this folder structure overview below. This way your hotfixes and upgrades remain entirely localised and you remain safe from harm!
Development
Kentico 1
CMSApp.sln
CMS
CMSApp_AppCode.csproj
References My.CustomBusinessLogic and My.SharedCore
Kentico 2
CMSApp.sln
CMS
CMSApp_AppCode.csproj
References My.SharedCore only
Kentico 3
CMSApp.sln
CMS
CMSApp_AppCode.csproj
My.CustomBusinessLogic
My.CustomBusinessLogic.csp
My.SharedCore
My.SharedCore.csproj
From a development standpoint you should be fine. When performing upgrades, hotfixes or new installs this may cause problems because the KIT looks at the actual .sln file or the actual root directory the .sln file is in.
What I would do is setup a solution like this and try out an upgrade and a hotfix and some local development.
This question already has answers here:
Developer Documentation: Sharepoint Document Management vs. ScrewTurn Wiki [closed]
(11 answers)
Closed 7 years ago.
Duplicate
Developer Documentation: Sharepoint Document Management vs. ScrewTurn Wiki
I have been tasked with picking a wiki tool for a development organization, comprised of several different development teams. Sharepoint is installed and upper management would prefer this to be used, but in the past it has only used when PMs are forced to use it. None of the developers will update it with content that needs to be shared. I developed in Sharepoint and I liked it, so I have nothing against it. But for this to work I need something I can get everyone using, so Sharepoint will not work.
Step one is to convince management why Sharepoint will not work. We need the typical wiki features:
WYSIWYG, Clean interface, Easy to use, Attach Files to pages, Support for groups of users, Open source, Hosted Locally. (Maybe others I am not considering now?)
Can anyone provide a list of objective reasons why Sharepoint is not the solution we can use to take our first step?
There are many such products out there so step 2 should be easier.
SharePoint is the exact opposite of a wiki: A wiki is lightweight, easy to use, obvious, quick, doesn't get in the way.
To elaborate: A wiki allows your to jot down an idea quickly and moving details to the next page. In SP, people start to create processes, editing rights, workflows.
Wikis are designed to not get in the way. SP is designed to prevent you from doing "something bad"; whatever that might be. Wikis are driven by the idea that brainstorming works in open space while SP is driven by FUD: Who can see this information? Can it be used against me? How can I prevent someone to see/edit something?
Note: This is not a critique of SP per se; it's just how it used in most organizations. If you look at the security settings and edit rights, you sometimes feel like the workers of the company must all have been inmates in some high-profile prison (or should be).
I have absolutely no sharepoint-foo at all, but the sharepoint setup by IT at my employer has a wiki that we can use for documentation. Wouldn't that be good enough? Works ok-ish in firefox on mac, so I'm a happy camper.
SharePoint is best when using many of it's features (eg DM, WCM, workflow, collaberation etc) - you get a lot of it's benefits from the synergy of using all these things together with a common interface.
In any one area though, it's far from the 'best of breed' application - so, if you want a product for a specific job (eg a wiki), SharePoint isn't the most fully-featured/easy-to-use/delete-as-applicable product to be using - there will be products that do that (single) job far better.
You could also try looking at this question to see others experiences with SharePoint wiki's
I have used MediaWiki, Instiki and Sharepoint. Sharepoint does not work correctly with firefox on purpose. Its wiki functionality is an after thought. All kinds of additional features nobody use. But it does appeal to managers.
Instiki can be up and running in less than a minute and MediaWiki has everything you could need. Sharepoint annoyed most people on our team so nobody wanted to use it which meant a lot of knowledge was lost.
Which version of SharePoint are you using WSS 3.0/MOSS 2007 includes both wiki and blog functionality.
Although the SharePoint wiki isn't as feature-rich as most, the fact is that if your developers would not update a SharePoint wiki, chances are that they would not update any other kind, either.
I recommend creating a SharePoint wiki, and then actually reading the starting page, where it gives the definition of wikiwiki. I recommend only using a wiki (of any kind) for documents that can be written quickly, so that developers can get back to developing as soon as possible. Let the structure and accuracy grow over time. Just get the facts into the wiki quickly.
Wikis offer workflows, Document management and more too. I would disagree with those who say you can't do this in a wiki. Check out Confluence by Atlassian
Does anyone have any strategies/tips/traps for moving to Team System? Should it be done in baby steps, or all at once? Should we migrate our SourceSafe library over, or draw a line in the sand and move forward? Is it worth brining SharePoint into the mix? Any thoughts are appreciated.
I've never had to migrate to TFS, but have used it pretty extensively for the past couple of years.
Regarding your question on Sharepoint, we've found it pretty useful in conjunction with TFS. We use it primarily for documentation management and for storing other "non-technical" artifacts related to the project. Some dev teams advocate keeping documentation in source control alongside source code, which is OK, but in my experience our project stakeholders have an easier time accessing relevent project documentation via the Sharepoint portal than they would having to interface with source control.
I basically was able to distribute the URL to the sharepoint site associated with our TFS team project to the concerned non-technical team members and have been able to avoid constantly e-mailing documents around, so it's been great for us.
It may just be too much work to do it all at once.
I feel that it is easier to divvy out projects to different people one at a time.
That way they can move them across and ensure that each works okay before closing out the SourceSafe.
You will always want a backup of the SourceSafe "database" around just in case.
I do not know how to migrate from SourceSafe to TFS and keep the comments and versions.
By far the easiest it to just add the projects in, but having migrated that way in the past, we always missed the ability to find out what others had done to particular files.
If you find a way to migrate, I would go that way unless it is hideously expensive.
I am total beginner in SharePoint and I need some help in starting a project. I have to develop publishing site that will be delivered to the client. I would like to give client deployment experience like he would get when deploying standard ASP.NET application as much as possible. I plan to use Visual Studio 2008 with SharePoint extensions and maybe WSPBuilder or some other tools.
I also need help in structuring whole project.
Here is what I plan to do:
1. Develop minimal site definition
2. Create site from this defionition. How should I do this from code ? Use SharePoint Feature ? How should I activate it ?
3. Develop all the needed infrastructure for the site (master page, layouts, content types, ...) as SharePoint Features.
Is this correct and how should I develop all those parts so I can make a some kind install script so can client create get complete site with one click ?
Site definitions are complex no question about it, but they are very useful if you need to deploy to unrelated enviornments. If you are staying on the same server farm, maybe site definition is overkill. If you are going between domains (i.e. test & prod, then maybe they are worth looking into).
Another advantage to site definitions, esp. if delivering to a client is it feels more like a traditional deliverable. They will have a bunch of files (hopefully in source control) that are their custom site. I think that gives IT dept's a much warmer feeling than an XML file created from the SharePoint UI.
Another benefit of site definitions are you have a lot more control over the pages that make up the site. IMHO its easier to add master pages & custom CSS via site defintion that site template.
I am curious as to what are the 'moving parts' to the site you are trying to deliver? I think that answering that question will determine how to define the project's structure.
Generally, I think you are on the right track. Features and solutions are a must. I would stay away from VSeWSS, its buggy and clunky and generally terrible if you are trying to do anything complex. It tries to be so smart, that it leaves you no control.
That said, it really depends on what you are trying to do. If you are going to build a solution to deploy to the GAC with one assembly, and only building features supported by vsewss you may be fine.
If however, you want to develop, say a timer job wiring that into the VSeWSS feature framework gets tough. Also, if you need multiple assemblies in the solution. YMMV, but I had to junk it and find of a more flexible solution (hello NANT).
A lot of the work you will end up doing is building and checking, and re-checking XML configuration files. Bookmark the Feature Schema reference page on MSDN, you will be spending a lot of time going through it.
Finally, yes, if you have all of the parts packaged as features you should be able to develop a nice install script. Ultimately the script will need to call the STSADM (there are some really nice STSADM extensions here) commands necessary to create the site structure, add & deploy the solution & activate the features. You can start with a batch file, and get as complicated as you want.
Personally I don't find that creating a site definition is really that useful for the sites I have built. They can be very tricky to set up, because of their complex nature.
What I do is use the standard Publishing Site and then using features to add my additional componets (deployed via a SharePoint solution).
You can use Feature Stapling to connect up the feature to the Publishing Site creation.
I've also just done a blog post on how to programmatically modify the workflow which is created by default: http://www.aaron-powell.com/blog/february-2009/programmatically-modifying-sharepoint-workflows.aspx (that also has a link in the comments off to the Feature Stapling concept).
Then I use a combination of SharePoint Solution Installer (http://www.codeplex.com/sharepointinstaller) and batch files to install the components. SSI for all the SharePoint database level installs and batch files for the file system stuff.
Adding another answer, because I have more than 300 characters worth of stuff to say :(
RE: SharePoint solutions generator, again I would say your mileage may vary.
The biggest issue with SharePoint dev is managing all of the "magic strings" across the various configuration files. GUIDs and Fully Qualified Assembly names are the spit and glue that hold the whole thing together, and although it all makes sense its very difficult to manage.
The current crop of tool all try and alleviate the complexity of managing these things, but they require that you work in a certain way, so the tool knows how to inject the appropriate plumbing.
If you plan on doing a lot of work with SharePoint it really behooves you too learn to manage the plumbing yourself. Its painful up front, but really pays dividends.
Basically, I suggest you spend your time learning the platform and not the tools. Once you know the platform, using the tools will be much easier.
If you are doing this as a one-off engagement and just want to get it done, I'm sure you can get any of the tools you've mentioned to do the trick.
I would agree with the use of the out of the box publishing site definition, and then customizing it using Site Collection features (Master Page, Page Layouts, CSS) and site features (create lists, pages, sub sites, defining master pages of sites, etc...).
Feature stapling is great when you want to customize new sites (allow user to create new sites) of well known site templates, like customize the "My Site" look and feel. In this case I don’t think its very useful.
As a tool to help this task, I personally use STSDEV (http://www.codeplex.com/stsdev) to help in creating, programming, debugging and deploying my Sharepoint solutions.
First it creates a good project for Visual Studio (clean, or with some nice "starting point" definitions). Then it includes some “build configurations” that really helps with install, deploy and upgrade in the development machine.