enhance(): blog post entitled "When is gitea for you ?"
This commit is contained in:
parent
da48aac295
commit
1c3fc5c687
|
|
@ -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
264
content/posts/when-is-gitea-for-you.md
Normal 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 !
|
||||
Loading…
Reference in a new issue