+++ 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-what-is-that} [Gitea](https://gitea.io/en-us/) 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 {#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 {#gogs} We can't talk about _Gitea_ without mentioning [Gogs](https://gogs.io/), 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} [Gitlab](https://about.gitlab.com/stages-devops-lifecycle/) 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 {#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 {#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 {#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 {#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 {#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 {#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](https://docs.gitlab.com/ee/install/) 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 {#my-choice} If you've been following [this](https://blog.lazkani.io/) 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 {#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 !