Programmer and mathematician. Problem solver. Lover of clean code, coffee, cycling, running and Italian food.
Kotlin, Java, Spock (Groovy), PHP, Angular, MariaDB, ...
Around 6 persons. We took the step because there was a (partial) simple migration script, and the feature set of GitLab was greater. Mostly the useability of the interface was a lot better, which increased the productivity, communication and 'purposefulness' (is that a word) of the team.
Considering renting a VPS. You are probably right, there is more performance/storage/memory required per instance of GitLab. The most low cost solution might be better in your case. However, GitLab also has a hosted variant (gitlab.com/) which runs the Community Edition which is free to use (but your data is on their servers...).
The admin overhead is not an issue in my experience: The Omnibus package has around 1/month updates, is well maintained and is easy to update (usually a package manager, migration works out of the box).
Maturity: this might be an issue. GitLab is a very quickly innovating platform. In a few years they developed a modern application which now influences the big players like GitHub and Jira. However, I've noticed few bugs in the day-to-day usage, and if you stay one major version behind there are probably no issues.
Programmer and mathematician. Problem solver. Lover of clean code, coffee, cycling, running and Italian food.
Kotlin, Java, Spock (Groovy), PHP, Angular, MariaDB, ...
Great to hear. At the time, as far as I can remember, we used the script as can be found on github.com/moimael/trac-to-gitlab. It converts the most basic infrastructure entities to similar GitLab entities. Then, we manually added/updated some labels, and started using some of the GitLab features which were not available in Trac.
Also, we noticed some changes in our team workflow after the migration. Because of that, we changed some workflow specific things like labels and pipeline scripts to suit our needs.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Around 6 persons. We took the step because there was a (partial) simple migration script, and the feature set of GitLab was greater. Mostly the useability of the interface was a lot better, which increased the productivity, communication and 'purposefulness' (is that a word) of the team.
Considering renting a VPS. You are probably right, there is more performance/storage/memory required per instance of GitLab. The most low cost solution might be better in your case. However, GitLab also has a hosted variant (gitlab.com/) which runs the Community Edition which is free to use (but your data is on their servers...).
The admin overhead is not an issue in my experience: The Omnibus package has around 1/month updates, is well maintained and is easy to update (usually a package manager, migration works out of the box).
Maturity: this might be an issue. GitLab is a very quickly innovating platform. In a few years they developed a modern application which now influences the big players like GitHub and Jira. However, I've noticed few bugs in the day-to-day usage, and if you stay one major version behind there are probably no issues.
Would be interested in what you used to migrate from Trac->Gitlab as we're about to try it...
Great to hear. At the time, as far as I can remember, we used the script as can be found on github.com/moimael/trac-to-gitlab. It converts the most basic infrastructure entities to similar GitLab entities. Then, we manually added/updated some labels, and started using some of the GitLab features which were not available in Trac.
Also, we noticed some changes in our team workflow after the migration. Because of that, we changed some workflow specific things like labels and pipeline scripts to suit our needs.