11 KiB
+++ title = "When is Gitea for you ?" author = ["Elia el Lazkani"] date = 2021-08-13 lastmod = 2021-08-13 tags = ["gitea", "git"] categories = ["revision-control"] draft = false +++
As a platform engineer, you aim to choose the best tool for the job. Your goal is to minimize complexity as much as possible to minimize breakages and make it easier to recover. And when you think it's that simple, you get hit by the fact that the best tool for the job is determined out of a list of requirements.
Dive down with me on a thought experiment that made me choose the hidden diamond behind a lot of my projects; Gitea.
Gitea ?! What is that ?
Gitea is advertised as
Gitea is a community managed lightweight code hosting solution written in Go. It is published under the MIT license.
It is worth mentioning the bold statement the Gitea team proudly displays on the front page of the project. It reads...
Gitea - Git with a cup of tea A painless self-hosted Git service.
Why would they choose that to advertise over other things ?
If you dig in deeper into the project, you'll find that it is a golang project. It is written to be fully compiled into one binary, making deployments a breeze. It is also offered in container form.
Note
Yeah ? You read that ? I said container ! You're ears are ringing now, something inside your head started making plans on what you can do with that.
Worth mentioning projects
While talking about revision control self-hosted servers, I know most of you will shout at me if I don't talk about other options.
If you already did that, great job. Let's talk options.
Gogs
We can't talk about Gitea without mentioning Gogs, where the foremore was forked from.
The differences between both revolve, mostly, around features. They are both great projects and choosing between them goes down to what features do you need to have. But what we mention about Gitea deployment and configuration can be, mostly, applied to Gogs. One of the main missing features in Gogs is native integration with CI/CD. Hooks can be configured, though, to run pipelines if that's your preferred methond of triggering pipelines.
Gitlab
Gitlab as you can see from their webpage at date is a beast. It offers a lot more features and promises to handle your workflow. It comes with its own CI/CD. It also offers integration with a bootload of different projects right and left. You might, also, be interested to hear more if you're running Kubernetes.
It is also worth mentioning the slew of options offered to run Gitlab in the cloud. Making deployment and management a lot easier.
After reading all that, you might want to ask what the catch is. Well the catch is, unfortunately, complexity. It also requires more resources. This needs to be taken into account, especially in the cloud. Bottom line is, it will cost more.
Requirements
We, finally, get to the most important part of our project. We need to sit down and figure out our requirements. It is impossible to start any project without defining the requirements and the resources at our disposal. A few good questions to find answers to.
- What do I need this server for ?
- How big is my company ?
- How big is this server supposed to be ?
- How many repositories is it supposed to hold ?
- Where am I going to be deploying it ?
- What kind of integration do I need out of it ?
- How do I back it up ?
- How do I recover it ?
- How do I monitor it ?
- What can I afford ?
warning
If you're not thinking about how to back your server up, recover it and monitor it, you're doing it wrong !
Small company
If you're an individual or a small company, you probably have a small set of repositories. Your needs depend on the features you require, at that point. If you want a simple server that "just works", with reservations on the term. Then I would suggest Gogs or Gitea. They require limited resources and can handle a good amount of beating. There is nothing stopping you from going with Gitlab, but know that you will have to deal with the complexity of its management. Only you can decide whether this is worth it and how much complexity your team can handle among other infrastructure services they have to offer.
If you require native integration with CI/CD, then your choices go down to Gitea and Gitlab. If you want to be able to offer pages feature or native Kubernetes integration, then your option is limited to one; Gitea. But if those are not required and you have free rein over CI/CD and your requirement set is met by the integration offered by Gitea, there is no reason to choose anything else at that point simply because "everyone is using that tool". That's a bad reason !
Let's not forget the cost ! This is a big factor for small companies. If you can go by with a smaller instance running Gitea, it wouldn't make financial sense to run something that would require bigger tiers and thus cost more.
Medium to big company
Now, we're talking more complex requirements. We might be talking one big monolith for the whole company. We are definitely talking more features and more integrations with different tools. The options in this case can range from a bare git server all the way to propiarty tools.
If we're going to stick with the open source projects we mentioned so far. Gitea could squeeze into the medium company with all of its features but Gitlab definitely hits spot for most cases. If you're medium to big, you already made peace with the fact that you will handle complexity here. I would say try to study the case out of curiosity but you already know my answer. You know you have one choice here and the choice is Gitlab.
Note
It is worth noting here that I am assuming integration with LDAP (or some other authentication system), complex CI/CD, Kubernetes integration and much more.
If you're at this level, I'm assuming cost has a bigger margin than with smaller companies. You understand that the infrastructure needed is bigger to accomodate all of your engineers and the increase in cost is also expected. Entertaining the idea of limiting cost at this point is still valid, you have the best interest of your company as well after all.
Deployment
At this stage, you're already decided on the tool you'll be using moving forward. It meets all the requirements derived from the needs of the teams that are going to be using. It also meets your standards of complexity and stability.
Note
It is worth mentioning here that you should test the tools you're considering in a few POC trials. Get familiarised with it and the way it works. How is it configured, and if it suits your configuration method of choice.
You'll get the chance to test it thoroughly during the UAT round. You'll be attempting to break it and determine it's breaking point and behaviour.
It is crucial to get familiarised with the system you'll be managing. Get comfortable with it.
After that ramble, let's look at a few options of deploying each. I'm sure there are many different ways I will not think of, but they are all determined by the enviornment they are going to be deployed in.
Gitea/Gogs
These two projects come in binary form, easy to curl and run. It can also be
deployed in a container format.
One can use docker-compose or configuration management to manage the
containers.
You can automate the deployment, the backup, the restore and the monitoring easily. It can be done on a single box with external storage, it can also be done in Kubernetes with Persisent Volumes.
If you're big enough, you can even entertain the idea of offering it as a service for teams to deploy on their own.
These two projects offer a versatility of deployments, choose which one fits your environment and workflow best.
Gitlab
If we want to dig into the different methods in which you can deploy Gitlab, we'll need pages. In fact, Gitlab already has pages written on the different ways to deploy it.
They also have ways to do backup, restore and a way to monitor it. The documentation is extensive and so are the different ways of deployment, from bare metal all the way to Kubernetes.
Give yourself a bit more time to get familiarised with Gitlab before you jump in. Get comfortable with it, take your time. Find your comfort zone. Always refer to the documentation.
My choice
If you've been following this blog for a while, you already know I chose Gitea.
From the previous thought experiment, I deduced that Gitea or Gogs both fit my needs as an individual. They offer me all the features I require from a revision control server. They are simple and don't require too much maintenance. They are also cheap to run. I don't need a big server to run them, I save on my pocket !
The reason I chose Gitea over Gogs was the CI/CD native integration. I wanted to use CI/CD pipelines for my projects. In fact, this very blog is built using a pipeline integrated with Gitea.
I've been running Gitea for a few years now. I've grown fond of it. Upgrading is a breeze, it's basically changing a number. It has been rock solid all of these years and haven't given me grief. In fact, the only time I had issues with it was when I was determining the memory requirements of the database and the database kept crashing.
To top it off, backup is easy and so is restoration. I've, also, done a few migrations on the server over the years as it grew. I've got comfortable with it.
And to answer your final question, yes, I am monitoring it. Gitea exports Prometheus metrics. And yes, I get paged for it when it gets down. Why ? Because I can. And because I am that kind of engineer.
Conclusion
When deciding on a tool to use, don't let your preference cloud your judgement. Be analytical in your approach and base it on requirements. Make your requirements clear and known as they are your guidance towards the right tool. Do not be afraid to take your time with it, run a few POCs. Play around with the project a bit, this time is valuable and could save you loads of headaches later on. Gather as much information as possible and assess how well this tool fits your needs. The best tool is the one that fits your needs best. End of story !