GitLab 8.16 Released with auto deploy on GKE and Prometheus monitoring
about.gitlab.com
about.gitlab.com
Now, if they somehow get to have these monitoring numbers automatically sent back to a centralized server where they can gather more insights about various installations, that would be killer, but I am not sure about the feasibility, giving the privacy implications (although plenty of open source software does it).
We indeed publish a list of requirements https://docs.gitlab.com/ce/install/requirements.html
But this is not enough. Not all hardware is created equal (one core is faster than another) and not all users are created equal (one might push many more branches per day). So to help people with the performance of their GitLab server we think the integrated metrics will be a large benefit.
But another important reason to add this is to ensure that GitLab has metrics about applications that are deployed with GitLab.
> Now, if they somehow get to have these monitoring numbers automatically sent back to a centralized server where they can gather more insights about various installations, that would be killer, but I am not sure about the feasibility, giving the privacy implications (although plenty of open source software does it).
We're very conscious of the privacy implications of sending data about GitLab usage back. We're doing that not with Prometheus but with a usage ping in GitLab EE. We're working on bringing that usage ping to CE, for our reasoning see https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/...
BTW People can use Prometheus monitoring in three forms: on-premise centralized, on-premises federated, and as a SaaS
On-premises centralized is what we just shipped.
Prometheus is easy to federate, where some of the metrics of a server are included in another one. In the future we might give every deployed application its own Prometheus server in a pod.
If you want to use Prometheus as a SaaS we recommend Weaveworks https://www.weave.works/solution/prometheus-monitoring/
Which is also open source! https://github.com/weaveworks/cortex
>This release migrates project related statistics to a separate table, removing existing columns in the process. This migration process requires downtime, and can take 10-15 minutes for large installations.
Any place i can eyeball this upgrade script first?
Incidentally, Im curious to know (to try and learn) how do you guys test this kind of stuff? do you have lots of different databases saved over that you try this kind of a major db upgrade on?
[0]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/db/migra...
[1]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/db/migra...
Redmine is still better from the project management planning and control POV (i.e. issues can be in different queues, but still form a coherent hierarchy, milestones consisting from issues and the control of time spent/still required to finish them; the work needed can be not only programming, but also other activities, etc.).
Gitlab is much nicer for the developers.
So for a private project, Gitlab might be a worth to try.
Only negative is that you need quite a beefy server to run it (compared to say Gitea or Gogs), but it's a small price to pay.