4 ms·

We also announced today where we'll take GitLab in the future with complete DevOps, for more information please see the live event recording or slides https://a

by sytse 9y ago

We also announced today where we'll take GitLab in the future with complete DevOps, for more information please see the live event recording or slides https://about.gitlab.com/2017/10/09/gitlab-raises-20-million-to-complete-devops/ https://about.gitlab.com/2017/10/09/gitlab-raises-20-million...

sinaa 9y ago
Really happy for GitLab and wish you guys all the best (and luck). We've been using Gitlab for all our company's development, however, one major issue that is pushing us to switch over to GitHub is the fact that GitLab goes down almost every other day (or sometimes every day) due to deployments. Although during this often the site remains available, when CI is not executed or triggers are not performed, it is still extremely disruptive. I really hope that you prioritise having disruption-free deployments.
- sytse 9y ago
  Thanks for your comment. Self hosted GitLab has been very reliable but GitLab.com's availability has been far below par. It is our nr. 1 focus to improve this. Deployments should not cause disruptions. Over the last few months we solved the speed of GitLab.com. Availability is next.
  - lucideer 9y ago
    Firstly, I'm really happy to see Gitlab growing and desperately want to see it succeed. We need an open-source alternative, and the organisational transparency within the company is also wonderful. However... > we solved the speed of GitLab.com I'm currently browsing a repo tree and each page is taking 5+ seconds to load (I am literally browsing HN while waiting for pages to open). This is a common experience. Please please don't get complacent. Not yet.
    - sytse 9y ago
      Thanks, I wanted to indicate our primary focus moved from the speed to the availability. But you're very right that there is still much to improve. We're not happy until every page is fast. Specifically about the repo tree page load: 1. I'll share this comment with our VP of Eng 2. We're working on Gitaly to make git calls faster. 3. We're working on a multifile editor to make browsing faster. BTW Here is a graph of how some of the other pages improved https://www.dropbox.com/s/8ztha1av8t0fcau/Screenshot%202017-10-10%2008.59.11.png?dl=0 https://www.dropbox.com/s/8ztha1av8t0fcau/Screenshot%202017-...
      - lucideer 9y ago
        Thanks. Good feedback to hear.
    - suprememoocow 9y ago
      I'm the Gitaly Lead at GitLab. Gitaly is a GitLab project to move all the git operations out of the GitLab Ruby monolith into a Git RPC service. https://gitlab.com/gitlab-org/gitaly/ https://gitlab.com/gitlab-org/gitaly/ We're hoping to complete this by the end of the year. Once it's done, we'll be able to end our reliance on NFS, which should greatly improve performance and uptime on GitLab.com and other large GitLab instances. In fact, we're already seeing some big performance payoffs as we bring services online. > Please please don't get complacent. Not yet. I can confirm that this is not the case. We're focused and working really hard to improve performance and we're also working hard to improve our metrics, so that we can target optimizations where we can gain greatest benefit. It's also worth pointing out that routinely experiencing 5+ second render times on browsing a repo homepage is outside our 99th percentile latencies for that route. I'd be interesting in digging into it further. Would you mind creating an issue in https://gitlab.com/gitlab-org/gitaly/issues/new https://gitlab.com/gitlab-org/gitaly/issues/new (mark it as confidential if you wish) and ping me `@andrewn`.
      - lucideer 9y ago
        The 5+ second delay is a little above the average (I'm rarely frustrated enough to actually go off and get distracted by HN while I wait), but notable delays on loading repo trees are definitely common, if not usually quite so high.
        suprememoocow 9y ago
        Repo tree rendering is a known issue that we're currently looking into: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/14680 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/14680 We hope to make improvements in this area soon. Hopefully you'll notice them!
freehunter 9y ago
Quick question: for my side project I currently pay money monthly for both Cloud9 and GitHub, but I am very open to switching tools. One of the things I love about storing code in the cloud and manipulating code in the cloud is that absolutely nothing needs to touch my local machine, which means I'm free to use (almost) whatever machine I want with (almost) any browser or (almost) any platform I want. It also means switching costs are next to nil, since I don't have to worry about if it runs on a Mac or Windows or what native tooling I have. However, a big problem I've discovered with Cloud9 is that it doesn't run on iOS and there are seemingly no plans to make that happen. I'm beginning to transfer over a lot of my work to an iPad, and with the incredible power offered by modern iOS systems, not supporting the platform seems a huge miss. I see in your slides you're working on a web IDE for GitLab, and in some of the comments on the open issue, iOS is mentioned. Can you answer if mobile platforms like iOS are really in the roadmap? As a paid customer, I'd switch in a heartbeat if I could use the same IDE on my Mac, PC, and iPad.
- sytse 9y ago
  Thanks for asking. I totally get the request. My cofounder Dmitriy likes his iPad a lot and wants to do more coding on it. Unfortunately it seems that the Monaco editor does not support mobile browsers https://github.com/Microsoft/monaco-editor/blob/master/README.md https://github.com/Microsoft/monaco-editor/blob/master/READM... But I've been very impressed with VS code's rapid improvements. I would love to know if mobile support is something they are looking into.
- jetsnoc 9y ago
  I'm using Cloud9 and Bitbucket. I was thinking just the other day how I would love to ditch my main rig for an iPad. Researching this some it looks like Duet or Puffin Browser gets Cloud9 mostly working.
  - freehunter 9y ago
    I do use Duet, but it's just an app to make an iPad a second monitor, it doesn't allow me to take it with me and leave my Mac at home. I'm not really understanding why anyone would build a web IDE in 2017 without iPad support. Web IDEs targeting x86 platforms are already plentiful and mature, and people on x86 platforms tend to ignore them for more traditional desktop IDEs because their computer can already run all of the code or containers they might need. But those don't really exist on an iPad, which I'd think is the ideal target for a cloud IDE.

by sytse 9y ago

sinaa 9y ago

Really happy for GitLab and wish you guys all the best (and luck). We've been using Gitlab for all our company's development, however, one major issue that is pushing us to switch over to GitHub is the fact that GitLab goes down almost every other day (or sometimes every day) due to deployments. Although during this often the site remains available, when CI is not executed or triggers are not performed, it is still extremely disruptive. I really hope that you prioritise having disruption-free deployments.

sytse 9y ago
Thanks for your comment. Self hosted GitLab has been very reliable but GitLab.com's availability has been far below par. It is our nr. 1 focus to improve this. Deployments should not cause disruptions. Over the last few months we solved the speed of GitLab.com. Availability is next.
- lucideer 9y ago
  Firstly, I'm really happy to see Gitlab growing and desperately want to see it succeed. We need an open-source alternative, and the organisational transparency within the company is also wonderful. However... > we solved the speed of GitLab.com I'm currently browsing a repo tree and each page is taking 5+ seconds to load (I am literally browsing HN while waiting for pages to open). This is a common experience. Please please don't get complacent. Not yet.
  - sytse 9y ago
    Thanks, I wanted to indicate our primary focus moved from the speed to the availability. But you're very right that there is still much to improve. We're not happy until every page is fast. Specifically about the repo tree page load: 1. I'll share this comment with our VP of Eng 2. We're working on Gitaly to make git calls faster. 3. We're working on a multifile editor to make browsing faster. BTW Here is a graph of how some of the other pages improved https://www.dropbox.com/s/8ztha1av8t0fcau/Screenshot%202017-10-10%2008.59.11.png?dl=0 https://www.dropbox.com/s/8ztha1av8t0fcau/Screenshot%202017-...
    - lucideer 9y ago
      Thanks. Good feedback to hear.
  - suprememoocow 9y ago
    I'm the Gitaly Lead at GitLab. Gitaly is a GitLab project to move all the git operations out of the GitLab Ruby monolith into a Git RPC service. https://gitlab.com/gitlab-org/gitaly/ https://gitlab.com/gitlab-org/gitaly/ We're hoping to complete this by the end of the year. Once it's done, we'll be able to end our reliance on NFS, which should greatly improve performance and uptime on GitLab.com and other large GitLab instances. In fact, we're already seeing some big performance payoffs as we bring services online. > Please please don't get complacent. Not yet. I can confirm that this is not the case. We're focused and working really hard to improve performance and we're also working hard to improve our metrics, so that we can target optimizations where we can gain greatest benefit. It's also worth pointing out that routinely experiencing 5+ second render times on browsing a repo homepage is outside our 99th percentile latencies for that route. I'd be interesting in digging into it further. Would you mind creating an issue in https://gitlab.com/gitlab-org/gitaly/issues/new https://gitlab.com/gitlab-org/gitaly/issues/new (mark it as confidential if you wish) and ping me `@andrewn`.
    - lucideer 9y ago
      The 5+ second delay is a little above the average (I'm rarely frustrated enough to actually go off and get distracted by HN while I wait), but notable delays on loading repo trees are definitely common, if not usually quite so high.
      - suprememoocow 9y ago
        Repo tree rendering is a known issue that we're currently looking into: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/14680 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/14680 We hope to make improvements in this area soon. Hopefully you'll notice them!

freehunter 9y ago

Quick question: for my side project I currently pay money monthly for both Cloud9 and GitHub, but I am very open to switching tools. One of the things I love about storing code in the cloud and manipulating code in the cloud is that absolutely nothing needs to touch my local machine, which means I'm free to use (almost) whatever machine I want with (almost) any browser or (almost) any platform I want. It also means switching costs are next to nil, since I don't have to worry about if it runs on a Mac or Windows or what native tooling I have. However, a big problem I've discovered with Cloud9 is that it doesn't run on iOS and there are seemingly no plans to make that happen. I'm beginning to transfer over a lot of my work to an iPad, and with the incredible power offered by modern iOS systems, not supporting the platform seems a huge miss. I see in your slides you're working on a web IDE for GitLab, and in some of the comments on the open issue, iOS is mentioned. Can you answer if mobile platforms like iOS are really in the roadmap? As a paid customer, I'd switch in a heartbeat if I could use the same IDE on my Mac, PC, and iPad.

sytse 9y ago
Thanks for asking. I totally get the request. My cofounder Dmitriy likes his iPad a lot and wants to do more coding on it. Unfortunately it seems that the Monaco editor does not support mobile browsers https://github.com/Microsoft/monaco-editor/blob/master/README.md https://github.com/Microsoft/monaco-editor/blob/master/READM... But I've been very impressed with VS code's rapid improvements. I would love to know if mobile support is something they are looking into.
jetsnoc 9y ago
I'm using Cloud9 and Bitbucket. I was thinking just the other day how I would love to ditch my main rig for an iPad. Researching this some it looks like Duet or Puffin Browser gets Cloud9 mostly working.
- freehunter 9y ago
  I do use Duet, but it's just an app to make an iPad a second monitor, it doesn't allow me to take it with me and leave my Mac at home. I'm not really understanding why anyone would build a web IDE in 2017 without iPad support. Web IDEs targeting x86 platforms are already plentiful and mature, and people on x86 platforms tend to ignore them for more traditional desktop IDEs because their computer can already run all of the code or containers they might need. But those don't really exist on an iPad, which I'd think is the ideal target for a cloud IDE.