Switching from Stash to GitLab - our experiences
807 views
Skip to first unread message
Divan Santana
Apr 4, 2016, 9:44:45 AM4/4/16
to gitl...@googlegroups.com
Hi All,
So I thought I'd post about our experiences switching from Atlassian
Stash to Gitlab CE at a banking institution from South Africa. As well
as ask some questions).
I think GitLab as a product and how the company is run, is simply
awesome. Enjoy reading the blogs and the "openness" of the company. I
also like the idea to try put as much data/content under git and GitLab
control.
So we decided to switch away from Stash (which we were paying for) and
switch to GitLab CE. Unfortunately some departments are still running
with Stash (and the various Atlassian products) but at least our
division isn't.
The good:
There is a lot. But some of the highlights for us have been:
1) It's blazing fast compared to Stash. It's like comparing a cheetah to
a turtle, seriously. In our case the turtle was also sick, and would
often time out and or have errors. Moreover the merges are kind of
asynchronous in GitLab compared to Stash where they appeared synchronous
and one would have to wait for each MR to
2) Omnibus is really great. There are so many reasons why we've found
omnibus great.
- We can and do automate the updates of GitLab nightly via
apt-get.
- Really quick and easy to get it up and running. And one can feel
confident it's well configured.
- The software stack gets updated too with GitLab updates.
3) Way more KISS solution. In every way. Which encourages users to use
the system more as well as makes sysadmin of the system easier too.
4) Being able to revert merges (not just commits) and via the web
interface is really nice.
5) RSS by default, nice stats integrated, WIP feature, milestones,
TODOs, integrated issue system, syntax highlighted diff etc.
6) Admin impersonate feature. This is really helpful under various
scenarios. It also helped with the migration.
7) Single page to view all MRs. This simple and crucial feature was
missing in Stash.
8) System resources. Before we had multiple nodes with beefy virtual
hardware. We now have one relatively low spec VM on vplex which performs
great as is HA enough for us.
9) Frequent/rapid development of GitLab :)
10) Documentation is simple and great.
11) The community focus and openness of development.
12) It's completely free software! (CE).
The drawbacks since switching from Stash:
1)
(This one is major for us. This may be a bug or perhaps it's something
we're doing wrong. I'm really not sure and have no idea how to debug
this further. So any tips here would be appreciated. I may go ahead and
file an issue if need be.)
The way our git process works is we have two long standing branches,
nonprod and production. We create new branches off production typically
make the change in the new branch and submit two MRs, one to nonprod and
one to production (which is selected as the default in the project).
The issue/bug(?), is
a) The diffs view (Changes) view for the nonprod MR is incorrect IMO and
differs from that of the production MR. It shows commits that aren't
from the branch I created. I think these commits are always merge
commits. The issue is that the diff view then shows changes/diffs for
changes that aren't from the source branch. *These "extra" changes have
already been merged into the target branch*. So the diff appears
incorrect. The MR to the target production(default) branch is always
correct/perfect. There are no extra merge commits and the diffs are
always correct, ie just the things I changed/just the difference between
the source and target branch. It doesn't show these extra invalid
changes that have already been merged.
b) When this occurs the title for the MR for the target nonprod will be
set to the branch name (with the underscores stripped and the title
capitalised.) This differs from the target production(default) MR, that
MR title is set to from the commit in the branch. This makes the MR
overview screen confuses because one can't easily see the two MRs are
the same, just to a different target.
I unfortunately can't consistently reproduce the issue, it happens
randomly. The above description is what happens when the issue occurs.
How can I debug this further? Should I log an issue for this? I think it
may be a bug in GitLab as this didn't occur while we were with Stash.
Unless it's something we're doing wrong.
2) When submitting a new MR, the source branches aren't sorted by last
modified/updated. Therefore one needs to type in(and remember the name)
of the branch name when submitted a new MR. Rather then likely just
clicking the branch from the top of the list. Similarly other views,
like the MR Merged page, I think, should be displayed by Last updated by
default.
3) Stash's PR/MR view was a little "clearer". Specifically one could see
the source branch name and the target branch name from the overview
screen. We find this very helpful. GitLab only shows the target branch
name, if it's not the default target branch. It also doesn't show the
source branch name which we find helpful.
4) We miss the ability to approve MRs and or require mandatory
reviewers. However it's understandable for this to be missing in the CE
edition and still makes the switch well worth it.
Other nice to haves:
5) We use the thumbs up/down to "approve" MRs. A proposal would be that
when one thumbs up/down a MR it shouldn't count or increment the chat
bubble icon on the MR dashboard view. The reason is that it's nice to
look at the MR overview page and see if a MR is approved or not while
being able to see if there is comments on the MR. ie differentiate
between the two the MR overview page.
6) Having a automatically merge this at date/time would be great. As
some of our changes (in an infrastructure as code environment) happen as
specific date/times.
I'd like to log issues/proposals for some of the above. However I
thought I'd post here first and take it from there.
Summary:
The actually switch from Stash to GitLab CE was also very easy and
problem free.
Overall, switching from paid for Stash to the free GitLab CE has been an
a wonderful *major upgrade* for us and made our working environment so
much better. It's a pity we never switched earlier.
Thanks to all and keep up the great work.
--
Best regards,
Divan Santana
--
Best regards,
Divan Santana
Red Hat Certified Architect
RHCA | CCNA | MCSE
Mobile: +27 82 787 8522
Email: di...@santanas.co.za
So I thought I'd post about our experiences switching from Atlassian
Stash to Gitlab CE at a banking institution from South Africa. As well
as ask some questions).
I think GitLab as a product and how the company is run, is simply
awesome. Enjoy reading the blogs and the "openness" of the company. I
also like the idea to try put as much data/content under git and GitLab
control.
So we decided to switch away from Stash (which we were paying for) and
switch to GitLab CE. Unfortunately some departments are still running
with Stash (and the various Atlassian products) but at least our
division isn't.
The good:
There is a lot. But some of the highlights for us have been:
1) It's blazing fast compared to Stash. It's like comparing a cheetah to
a turtle, seriously. In our case the turtle was also sick, and would
often time out and or have errors. Moreover the merges are kind of
asynchronous in GitLab compared to Stash where they appeared synchronous
and one would have to wait for each MR to
2) Omnibus is really great. There are so many reasons why we've found
omnibus great.
- We can and do automate the updates of GitLab nightly via
apt-get.
- Really quick and easy to get it up and running. And one can feel
confident it's well configured.
- The software stack gets updated too with GitLab updates.
3) Way more KISS solution. In every way. Which encourages users to use
the system more as well as makes sysadmin of the system easier too.
4) Being able to revert merges (not just commits) and via the web
interface is really nice.
5) RSS by default, nice stats integrated, WIP feature, milestones,
TODOs, integrated issue system, syntax highlighted diff etc.
6) Admin impersonate feature. This is really helpful under various
scenarios. It also helped with the migration.
7) Single page to view all MRs. This simple and crucial feature was
missing in Stash.
8) System resources. Before we had multiple nodes with beefy virtual
hardware. We now have one relatively low spec VM on vplex which performs
great as is HA enough for us.
9) Frequent/rapid development of GitLab :)
10) Documentation is simple and great.
11) The community focus and openness of development.
12) It's completely free software! (CE).
The drawbacks since switching from Stash:
1)
(This one is major for us. This may be a bug or perhaps it's something
we're doing wrong. I'm really not sure and have no idea how to debug
this further. So any tips here would be appreciated. I may go ahead and
file an issue if need be.)
The way our git process works is we have two long standing branches,
nonprod and production. We create new branches off production typically
make the change in the new branch and submit two MRs, one to nonprod and
one to production (which is selected as the default in the project).
The issue/bug(?), is
a) The diffs view (Changes) view for the nonprod MR is incorrect IMO and
differs from that of the production MR. It shows commits that aren't
from the branch I created. I think these commits are always merge
commits. The issue is that the diff view then shows changes/diffs for
changes that aren't from the source branch. *These "extra" changes have
already been merged into the target branch*. So the diff appears
incorrect. The MR to the target production(default) branch is always
correct/perfect. There are no extra merge commits and the diffs are
always correct, ie just the things I changed/just the difference between
the source and target branch. It doesn't show these extra invalid
changes that have already been merged.
b) When this occurs the title for the MR for the target nonprod will be
set to the branch name (with the underscores stripped and the title
capitalised.) This differs from the target production(default) MR, that
MR title is set to from the commit in the branch. This makes the MR
overview screen confuses because one can't easily see the two MRs are
the same, just to a different target.
I unfortunately can't consistently reproduce the issue, it happens
randomly. The above description is what happens when the issue occurs.
How can I debug this further? Should I log an issue for this? I think it
may be a bug in GitLab as this didn't occur while we were with Stash.
Unless it's something we're doing wrong.
2) When submitting a new MR, the source branches aren't sorted by last
modified/updated. Therefore one needs to type in(and remember the name)
of the branch name when submitted a new MR. Rather then likely just
clicking the branch from the top of the list. Similarly other views,
like the MR Merged page, I think, should be displayed by Last updated by
default.
3) Stash's PR/MR view was a little "clearer". Specifically one could see
the source branch name and the target branch name from the overview
screen. We find this very helpful. GitLab only shows the target branch
name, if it's not the default target branch. It also doesn't show the
source branch name which we find helpful.
4) We miss the ability to approve MRs and or require mandatory
reviewers. However it's understandable for this to be missing in the CE
edition and still makes the switch well worth it.
Other nice to haves:
5) We use the thumbs up/down to "approve" MRs. A proposal would be that
when one thumbs up/down a MR it shouldn't count or increment the chat
bubble icon on the MR dashboard view. The reason is that it's nice to
look at the MR overview page and see if a MR is approved or not while
being able to see if there is comments on the MR. ie differentiate
between the two the MR overview page.
6) Having a automatically merge this at date/time would be great. As
some of our changes (in an infrastructure as code environment) happen as
specific date/times.
I'd like to log issues/proposals for some of the above. However I
thought I'd post here first and take it from there.
Summary:
The actually switch from Stash to GitLab CE was also very easy and
problem free.
Overall, switching from paid for Stash to the free GitLab CE has been an
a wonderful *major upgrade* for us and made our working environment so
much better. It's a pity we never switched earlier.
Thanks to all and keep up the great work.
--
Best regards,
Divan Santana
--
Best regards,
Divan Santana
Red Hat Certified Architect
RHCA | CCNA | MCSE
Mobile: +27 82 787 8522
Email: di...@santanas.co.za
sytse
Apr 4, 2016, 12:10:05 PM4/4/16
to GitLab, di...@santanas.co.za, Job van der Voort
Thanks Divan for your kind words, glad to hear GitLab is a major upgrade for you! I've asked Job to respond to your comments.
Divan Santana
Apr 8, 2016, 6:59:13 AM4/8/16
to Job van der Voort, sytse, GitLab
Thanks Job and Sytse for feedback.
> > *The issue/bug(?), is a) The diffs view (Changes) view for the nonprod MR
> Showing diffs and MRs correctly should be absolutely solid, so I'm very
> interested in trying to replicate this.
Glad to hear so. That's what I would expect too.
> Could you provide me with an example repo / a way to create one?
The only repos I've seen this issue on is our two main/bigger repos. Any
new repos I've created to try reproduce the issue I haven't been able to
recreate the bug there.
Our instance isn't internet facing so can't give access.
> It wasn't clear to me from which branch you branch off and how nonprod fits
> into that.
Apologies, meant to mention that. Branches are created off the
production branch(our default branch). production -> name_mychange. We
then submit two MRs, 1 name_mychange branch to target nonprod branch and
2 another to target production.
> > *b) When this occurs the title for the MR for the target nonprod will
> What would be a better name in your situation? Adding information in the
> title about the target branch or just providing more information in the
> list of MRs / on the MR view?
The question is not really which name is better in our situation. The
main issue is that it sometimes picks the MR title name from the branch
and sometimes picks the MR title name from the commit. So the same
branch submitted to target nonprod branch, it would sometimes pick the
branch name as the MR title. The same branch submitted to the target
production branch, it would pick the commit log name as the name for the
MR title. I would expect both MRs with the same source branch to both
have the same title. Moreover when this occurs we notice the above
described wrong diff.
> > *How can I debug this further? Should I log an issue for this? I think
> You can always make an issue, which makes it easy to keep track of what
> happened. I do think that a replicable case will be necessary in order to
> fix this. Please also note your GitLab version and installation type when
> you do.
I'll try put some more effort in trying to reproduce this issue. Though
it's difficult because it seems random and I've only seen it in our main repos.
I'll create an issue for this to track it there.
> *2) When submitting a new MR, the source branches aren't sorted by
>
> Makes sense! I think we should do it. I've created an issue and scheduled
> this for a future release:
> https://gitlab.com/gitlab-org/gitlab-ce/issues/14989
Awesome - thanks. I know a lot of users will appreciate this.
> > *3) Stash's PR/MR view was a little "clearer". Specifically one could
>
> You mean the list of MRs?
Yes.
> This is a hard one! We have a lot of potential information for that list,
> depending on what you use and we have to balance the amount of information
> with its density.
> Is it an idea to include that information in the title of the MR instead
> (as suggested above)?
This is indeed a hard one. Let me think about it and try log a issue for
it.
It's made worse by the above issue, in that the MR title sometimes
differs even when two MRs both have the same source branch.
I think ultimately always showing the source branch, the target branch
would help a lot. Perhaps separating this information in columns would
help too. Currently GitLab doesn't show target branch if target branch
is the default. And it never shows the source branch name. Sometimes the
MR title is the source branch name, sometimes it's the MR title is
derived from the git commit.
> > *4) We miss the ability to approve MRs and or require mandatory reviewers.
> > We'll be adding approvals using emoji to GitLab CE in the future:
> > https://gitlab.com/gitlab-org/gitlab-ce/issues/13411
> For person-specific approvals, you will still need GitLab EE, but the
> functionality will be greater for CE than it is now.
That's very nice. I added my comments to that issue.
> > *Other nice to haves: 5) We use the thumbs up/down to "approve" MRs. A
> See above and here!
> https://gitlab.com/gitlab-org/gitlab-ce/issues/13411
#13411 issue may solve this one for us. :)
> > *6) Having a automatically merge this at date/time would be great. As some
> I'm not sure if this is something we'd do, but I understand the use case.
> Is at those times no one available to merge something? I'm happy to discuss
> alternative solutions.
I could see this being a EE only feature. I do think it would be cool
and helpful to some organisations. It's a common requirement for us, as
sometimes MRs need to go in at all sorts of strange times. So it would
be nice to review it during normal working hours and select it to be
merged automatically at "implementation time". Now our on call support
person would need to login and merge the MR at the appropriate time.
https://gitlab.com/gitlab-org/gitlab-ce/issues/15067
Created to track the idea.
> *I'd like to log issues/proposals for some of the above. However I thought
> I'd post here first and take it from there. *
>
> Great! Feel free to make issues at any time!
Thanks a ton for the feedback and great product.
> > *The issue/bug(?), is a) The diffs view (Changes) view for the nonprod MR
> > is incorrect IMO and differs from that of the production MR. It shows
> > commits that aren't from the branch I created. I think these commits are
> > always merge commits. The issue is that the diff view then shows
> > changes/diffs for changes that aren't from the source branch. *These
> > "extra" changes have already been merged into the target branch*. So the
> > diff appears incorrect. The MR to the target production(default) branch is
> > always correct/perfect. There are no extra merge commits and the diffs
> > are always correct, ie just the things I changed/just the difference
> > between the source and target branch. It doesn't show these extra
> > invalid changes that have already been merged. *
> > commits that aren't from the branch I created. I think these commits are
> > always merge commits. The issue is that the diff view then shows
> > changes/diffs for changes that aren't from the source branch. *These
> > "extra" changes have already been merged into the target branch*. So the
> > diff appears incorrect. The MR to the target production(default) branch is
> > always correct/perfect. There are no extra merge commits and the diffs
> > are always correct, ie just the things I changed/just the difference
> > between the source and target branch. It doesn't show these extra
> Showing diffs and MRs correctly should be absolutely solid, so I'm very
> interested in trying to replicate this.
Glad to hear so. That's what I would expect too.
> Could you provide me with an example repo / a way to create one?
The only repos I've seen this issue on is our two main/bigger repos. Any
new repos I've created to try reproduce the issue I haven't been able to
recreate the bug there.
Our instance isn't internet facing so can't give access.
> It wasn't clear to me from which branch you branch off and how nonprod fits
> into that.
Apologies, meant to mention that. Branches are created off the
production branch(our default branch). production -> name_mychange. We
then submit two MRs, 1 name_mychange branch to target nonprod branch and
2 another to target production.
> > *b) When this occurs the title for the MR for the target nonprod will
> > be set to the branch name (with the underscores stripped and the
> > title capitalised.) This differs from the target production(default) MR,
> > that MR title is set to from the commit in the branch. This makes the
> > MR overview screen confuses because one can't easily see the two MRs
> > are the same, just to a different target. *
> > title capitalised.) This differs from the target production(default) MR,
> > that MR title is set to from the commit in the branch. This makes the
> > MR overview screen confuses because one can't easily see the two MRs
> What would be a better name in your situation? Adding information in the
> title about the target branch or just providing more information in the
> list of MRs / on the MR view?
The question is not really which name is better in our situation. The
main issue is that it sometimes picks the MR title name from the branch
and sometimes picks the MR title name from the commit. So the same
branch submitted to target nonprod branch, it would sometimes pick the
branch name as the MR title. The same branch submitted to the target
production branch, it would pick the commit log name as the name for the
MR title. I would expect both MRs with the same source branch to both
have the same title. Moreover when this occurs we notice the above
described wrong diff.
> > *How can I debug this further? Should I log an issue for this? I think
> > it may be a bug in GitLab as this didn't occur while we were with
> > Stash. Unless it's something we're doing wrong. *
> You can always make an issue, which makes it easy to keep track of what
> happened. I do think that a replicable case will be necessary in order to
> fix this. Please also note your GitLab version and installation type when
> you do.
I'll try put some more effort in trying to reproduce this issue. Though
it's difficult because it seems random and I've only seen it in our main repos.
I'll create an issue for this to track it there.
> *2) When submitting a new MR, the source branches aren't sorted by
> last modified/updated. Therefore one needs to type in(and remember the
> name) of the branch name when submitted a new MR. Rather then likely
> just clicking the branch from the top of the list. Similarly other
> views, like the MR Merged page, I think, should be displayed by Last
> updated by default. *
> name) of the branch name when submitted a new MR. Rather then likely
> just clicking the branch from the top of the list. Similarly other
> views, like the MR Merged page, I think, should be displayed by Last
>
> Makes sense! I think we should do it. I've created an issue and scheduled
> this for a future release:
> https://gitlab.com/gitlab-org/gitlab-ce/issues/14989
Awesome - thanks. I know a lot of users will appreciate this.
> > *3) Stash's PR/MR view was a little "clearer". Specifically one could
> > see the source branch name and the target branch name from the
> > overview screen. We find this very helpful. GitLab only shows the target
> > branch name, if it's not the default target branch. It also doesn't show
> > the source branch name which we find helpful. *
> > overview screen. We find this very helpful. GitLab only shows the target
> > branch name, if it's not the default target branch. It also doesn't show
>
> You mean the list of MRs?
Yes.
> This is a hard one! We have a lot of potential information for that list,
> depending on what you use and we have to balance the amount of information
> with its density.
> Is it an idea to include that information in the title of the MR instead
> (as suggested above)?
This is indeed a hard one. Let me think about it and try log a issue for
it.
It's made worse by the above issue, in that the MR title sometimes
differs even when two MRs both have the same source branch.
I think ultimately always showing the source branch, the target branch
would help a lot. Perhaps separating this information in columns would
help too. Currently GitLab doesn't show target branch if target branch
is the default. And it never shows the source branch name. Sometimes the
MR title is the source branch name, sometimes it's the MR title is
derived from the git commit.
> > *4) We miss the ability to approve MRs and or require mandatory reviewers.
> > However it's understandable for this to be missing in the CE edition and
> > still makes the switch well worth it. *
> > We'll be adding approvals using emoji to GitLab CE in the future:
> > https://gitlab.com/gitlab-org/gitlab-ce/issues/13411
> For person-specific approvals, you will still need GitLab EE, but the
> functionality will be greater for CE than it is now.
That's very nice. I added my comments to that issue.
> > *Other nice to haves: 5) We use the thumbs up/down to "approve" MRs. A
> > proposal would be that when one thumbs up/down a MR it shouldn't count or
> > increment the chat bubble icon on the MR dashboard view. The reason is that
> > it's nice to look at the MR overview page and see if a MR is approved or
> > not while being able to see if there is comments on the MR. ie
> > differentiate between the two the MR overview page. *
> > increment the chat bubble icon on the MR dashboard view. The reason is that
> > it's nice to look at the MR overview page and see if a MR is approved or
> > not while being able to see if there is comments on the MR. ie
> See above and here!
> https://gitlab.com/gitlab-org/gitlab-ce/issues/13411
#13411 issue may solve this one for us. :)
> > *6) Having a automatically merge this at date/time would be great. As some
> > of our changes (in an infrastructure as code environment) happen
> > as specific date/times. *
> I'm not sure if this is something we'd do, but I understand the use case.
> Is at those times no one available to merge something? I'm happy to discuss
> alternative solutions.
I could see this being a EE only feature. I do think it would be cool
and helpful to some organisations. It's a common requirement for us, as
sometimes MRs need to go in at all sorts of strange times. So it would
be nice to review it during normal working hours and select it to be
merged automatically at "implementation time". Now our on call support
person would need to login and merge the MR at the appropriate time.
https://gitlab.com/gitlab-org/gitlab-ce/issues/15067
Created to track the idea.
> *I'd like to log issues/proposals for some of the above. However I thought
> I'd post here first and take it from there. *
>
> Great! Feel free to make issues at any time!
Thanks a ton for the feedback and great product.
Divan Santana
Apr 12, 2016, 11:13:32 AM4/12/16
to GitLab
Just to close the loop on this email thread. I logged an issue upstream
to track it.
> I'll create an issue for this to track it there.
https://gitlab.com/gitlab-org/gitlab-ce/issues/15140
to track it.
> I'll create an issue for this to track it there.
Reply all
Reply to author
Forward
0 new messages