Does this mean I can ewrite a web app, put the source on GitLab and have GitLab run the web app (ideally with very minimal hassle)?
If not, what does it mean? What is Gitlab letting me do now than (a) it didn't do before (b) Github doesn't do?
If not, what does it mean? What is Gitlab letting me do now than (a) it didn't do before (b) Github doesn't do?
You may want to check out (and sign up as a beta tester) for Cloud Seed, an open-source program led by GitLab Incubation Engineering in collaboration with Google Cloud: https://hello.cloudseed.app/
> Deploying web applications from GitLab to major cloud providers should be trivial.
Yes, that's what I want! I find it easy to develop web apps in Python, but a PITA to deploy them.
> Does this mean I can ewrite a web app, put the source on GitLab and have GitLab run the web app (ideally with very minimal hassle)?
Cloud Seed aims to make this easier, deploying the web application with minimal effort to your preferred cloud. More details in https://docs.gitlab.com/ee/cloud_seed/ and https://hello.cloudseed.app/ - it is a joint project from Google Cloud and GitLab.
In case you run your web app in a containerized stack, and prefer to deploy to Kubernetes, the integration with the Agent for Kubernetes has been greatly improved: https://docs.gitlab.com/ee/user/clusters/agent/
If you are looking to host static web apps (e.g. Hugo, etc.), GitLab Pages can help. More ideas in this blog post to choose a static site generator (SSG): https://about.gitlab.com/blog/2022/04/18/comparing-static-si...
> If not, what does it mean? What is Gitlab letting me do now than (a) it didn't do before (b) Github doesn't do?
Depending on which version you are at, new releases add features every month on the 22nd. GitLab 14.10 https://about.gitlab.com/releases/2022/04/22/gitlab-14-10-re... added the GitLab Runner Operator for Kubernetes for example. That's an integration after the create (SCM) and verify (CI) stage, ensuring that cloud native deployments deploy applications, and maintenance levels follow best practices. There are more stages in the DevOps lifecycle, such as package and release or protect and secure.
Observability for deployed applications, and ensuring that performance regressions do not reach production is also a very hot topic imho (shameless plug: join my talk at KubeCon EU to chat more https://kccnceu2022.sched.com/event/yttd?iframe=no :))
With regards what you can do now - I've written a blog post about my favourite hacks in GitLab a while ago, maybe there are some features or workflows that are useful for your environment: https://about.gitlab.com/blog/2021/10/19/top-10-gitlab-hacks...
That said, GitLab 15.0 is around the corner, coming May 22. https://about.gitlab.com/upcoming-releases/ I'm personally most excited about the Podman support for GitLab runner, helping with containerized CI/CD infrastructure as alternative to Docker as executor.
The GitLab direction handbook provides more insights for future plans: https://about.gitlab.com/direction/ Recommend diving into the stages and review based on your requirements, or potential new ideas and use cases. If you miss anything, please open feature proposals to collaborate: https://gitlab.com/gitlab-org/gitlab/-/issues Thanks :)
I've never used Kubernetes, but have seen it described as a PITA to set up and use, which is why I'm not keen on it.
https://gitlab.com/gitlab-org/gitlab/-/issues/213185
I'd join many participants in advising anyone to think very carefully before adopting GitLab.
What would you recommend instead? Gitea?
The issue tracking and labelling system is fine for what it is, but not good enough for planning projects. The Epics and Milestones functionality appears thrown together and isn't useful for much (we tried). Missing features such as persistent links to milestones (links are essentially a text string), lack of workflows ("You can do anything! Just ... use labels"), Milestones lack a change history, lack of nested Epics.
We want to be able to use confidential issues every now and again, which mean that everyone in the org needs a seat license to contribute or even view. If you want nested Epics you have to jump from $240 /seat/year to $1200 /seat/year for every single seat (hence the above linked issue).
Fundamentally they are trying to be the "everything" platform, and their sales material suggets that you can drop subscriptions to all kinds of competitors. Our experience was that the features weren't quite good enough.
I don't necessarily expect things to get worse. I just find that the tools aren't quite good enough to justify the sales talk, and seeing them expand the breadth of feature set without improving core stuff is disappointing.
We're staying with GitLab for code and dev team, because we're already there and we've built CI pipelines etc. But moving to Jira for issue tracking and planning, and so far it's much nicer.
EDIT: Just noticed that they closed the issue [0] with a glib "opportunities to help customers derive more value from GitLab".
Wow, Jira being better is really damning. FWIW, there's a lot of competitors to Jira these days, and most of them are much better. We're using Shortcut, and it's been excellent.
We did evaluate Shortcut (formerly Clubhouse) and I did talk to a sales engineer.
We weren't able to make our issues open to the public, which was a serious blocker.
It wasn't clear how we would differentiate between user stories, bug tracking, epics, planned work, etc. And how to handle and track support and operational issues.
The response in the org (we're not all devs) has been almost universally positive, and very favourable compared to our GitLab issue-tracking experience.