diff --git a/content-org/blog.org b/content-org/blog.org index b4e0cb4..4d6c0d6 100644 --- a/content-org/blog.org +++ b/content-org/blog.org @@ -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 +
+

Note

+#+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 +
+#+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 +
+

warning

+#+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 +
+#+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 +
+

Note

+#+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 +
+#+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 +
+

Note

+#+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 +
+#+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: diff --git a/content/posts/when-is-gitea-for-you.md b/content/posts/when-is-gitea-for-you.md new file mode 100644 index 0000000..5bd7a1d --- /dev/null +++ b/content/posts/when-is-gitea-for-you.md @@ -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**. + + + + +## 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 !