elia/blog.lazkani.io
1
0
Fork 0
Code Issues Pull requests Packages 1 Wiki Activity

enhance(): blog post entitled "When is gitea for you ?"

Browse source
This commit is contained in:
Elia el Lazkani 2021-08-14 00:08:36 +02:00
parent da48aac295
commit 1c3fc5c687
2 changed files with 527 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

263
content-org/blog.org
View file

@ -6304,6 +6304,269 @@ Indeed, I did. The old repository was renamed and archived [[https://gitea.proje
After I pushed the repository you can notice the change in size. It's not insignificant.
I think it's clearner now. The *1.2MB* size on the /repository/ is no longer
bothering me.
*** TODO When is Gitea for you ? :gitea:git:
:PROPERTIES:
:EXPORT_HUGO_LASTMOD: 2021-08-13
:EXPORT_DATE: 2021-08-13
:EXPORT_FILE_NAME: when-is-gitea-for-you
:CUSTOM_ID: when-is-gitea-for-you
:END:
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*.
#+hugo: more
**** Gitea ?! What is that ?
[[https://gitea.io/en-us/][Gitea]] is advertised as
#+begin_quote
Gitea is a community managed lightweight code hosting solution written in Go. It is published under the MIT license.
#+end_quote
It is worth mentioning the bold statement the *Gitea* team proudly displays on
the front page of the project. It reads...
#+begin_quote
Gitea - Git with a cup of tea
A painless self-hosted Git service.
#+end_quote
/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.
#+BEGIN_EXPORT html
<div class="admonition note">
<p class="admonition-title">Note</p>
#+END_EXPORT
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.
#+BEGIN_EXPORT html
</div>
#+END_EXPORT
**** 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 [[https://gogs.io/][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
[[https://about.gitlab.com/stages-devops-lifecycle/][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 ?
#+BEGIN_EXPORT html
<div class="admonition warning">
<p class="admonition-title">warning</p>
#+END_EXPORT
If you're not thinking about how to *back* your server *up*, *recover* it and
*monitor* it, you're doing it wrong !
#+BEGIN_EXPORT html
</div>
#+END_EXPORT
***** 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/.
#+BEGIN_EXPORT html
<div class="admonition note">
<p class="admonition-title">Note</p>
#+END_EXPORT
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.
#+BEGIN_EXPORT html
</div>
#+END_EXPORT
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.
#+BEGIN_EXPORT html
<div class="admonition note">
<p class="admonition-title">Note</p>
#+END_EXPORT
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.
#+BEGIN_EXPORT html
</div>
#+END_EXPORT
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* [[https://docs.gitlab.com/ee/install/][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 [[https://blog.lazkani.io/][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 !
** RSS :@rss:
*** DONE Yet Another RSS Reader Move ? :emacs:org_mode:configuration:
:PROPERTIES:

264
content/posts/when-is-gitea-for-you.md Normal file
View file

@ -0,0 +1,264 @@
+++
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 = true
+++
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**.
<!--more-->
## 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.
<div class="admonition note">
<p class="admonition-title">Note</p>
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.
</div>
## 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 ?
<div class="admonition warning">
<p class="admonition-title">warning</p>
If you're not thinking about how to **back** your server **up**, **recover** it and
**monitor** it, you're doing it wrong !
</div>
### 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_.
<div class="admonition note">
<p class="admonition-title">Note</p>
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.
</div>
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.
<div class="admonition note">
<p class="admonition-title">Note</p>
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.
</div>
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 !