自建使用 Git 仓库其实很久了，当时的原因很简单就是因为 Github 的私有仓库不是免费的。虽然期间也续费过 Github 会员好多年，但是毕竟还是自建来得吃香，就这样子兜兜转转用下来这个 Gitea 的实例看了下日期其实比我手头上使用的任何数码硬件设备都要久了。

当时的 Gitea 项目还不是很成熟，甚至连 CI 模块都没有需要搭配第三方 CI 平台来使用。而我自己个人也不喜欢 Gitlab 那么臃肿的架构设计，于是 Gitea 和 Drone CI 的搭配就一直这样子沿用了下来。

近期在整理 Git 仓库和代码的时候，顺手又将 Gitea 升级了下，发现已经是 1.21 版本了，还自带了 Gitea Actions。于是从精简系统的角度上考虑，是不是需要将其替换掉 Drone CI？从我调研以及使用的过程看来，答案是肯定的。

那么 Drone CI 有什么不足的地方呢，主要的问题有以下几点：

首先，原本的 Drone CI 是开源项目但是有完整的商业目标，因此在被 Harness 收购了以后开源的版本更新其实并不及时，这就导致界面非常的简陋，同时也和 Getea 的界面相差甚远。其次，Drone CI 是作为 Gitea 的应用来注册的，然后通过 WebHook 的方式来相互通信，这就导致会有不同的问题发生，例如权限、网络延迟以及缓存等等的问题。还有一点就是，随着研发团队人员的增加，很多时候权限的粒度需要精确的控制，Drone CI 至今都无法完成从全局（Global）、组（Organization）、项目（Project）程度的权限控制。

然后替换为 Gitea Actions 以后又将会获得什么好处呢？

首先就是完整的产品体验，至少界面以及权限这块是保持一致的。然后，Gitea Actions 和 Github Actions 保持了配置方面的兼容性，这让我原本需要分别配置两套 CI 的 yaml 一下子工作量就减轻了不少，同时 Github Actions 丰富的生态也可以在 Gitea Actions 上得以延续。

当然，目前还有一点需要注意的是，Gitea 官网上说明 Gitea Actions 还在开发阶段功能方面不是很稳定，可能随时需要更新。所以切换到 Gitea Actions 以后，那么需要随时关注更新版本（但至少从我目前几个项目的配置看来，没有发现大的问题）。

总体来说，Drone CI 任然还是非常优秀的 CI 平台，只是随时时间的推移可能目前来说已经不适合我而已。对于 Drone CI 的情感还是非常的感激的，毕竟陪伴了我很多日夜的开发之路。

20230220: Azure 因为不可抗力还是暂时迁移到了腾讯云的轻量服务器，以后是否还需要继续迁移还是看情况吧。

距离上次的迁移已经有两三年了，一般来说不会这么折腾的，但是国内对外的网络环境是越来越糟糕。

这个博客站点其实也是佛系更新的，加上天生爱自由的关系不想备案（其实早先备过案，但过期了），于是就又得换个地方、
换个国内能够访问稍微顺畅点的。

用过很久的 Linode，然后再是 Vultr 。就现在这个网络环境来看，这些国外老牌但是规模来说二线的云服务商是
国内老大哥重点关照的对象，毕竟个人站长以及「散户」太多，监管起来成本太高还不如一刀切。

所以，这次考虑迁移还是想往相对比较大的平台服务商上面去靠拢，同时为了省事宁可多些花费，加上又不想用国产
的服务商（别问我为什么）。于是剩下的也就是三家：Google 的 GCP、亚马逊的 AWS 以及微软的 Azure 。

不用 Google 是因为不想把鸡蛋放在一个篮子里，而 AWS 那逆天的控制面板简直让人感觉这是不是和我们一个星球的人
设计出来的，那么剩下就只能选用了 Azure 这其实完全不是好不好问题了。

Azure 的费用的确不便宜，但希望贵有贵的道理吧。现在写博客的人是越来越少了，希望我也还能继续坚持下去。

前些天喷了下所谓的前端「娱乐圈」，虽然带有点情绪但是应该能说明我的目前前端这个圈子的态度。

昨晚收到前同事的来信，虽然带过的团队和人较多，真的尴尬记不起来您是谁来，但真的非常感动那么多年过去还能想起不才。

我觉得还是有必要再继续写篇我自己个人从前端转型的历程和心态。其实这个话题其实已经不止讨论过一次，但其实以前我把这件事情自己也就当做过往来调侃而已，没有非常认真的分析。

我想现在看来，是个非常好的时间点来说这个事情：一来当作自己的个职业方面的总结、二来也可以抛砖引玉当作各位的参考，见笑。

如果时间拨回到十几年前，那时候的前端职位的定位和职责其实非常的模糊，对于前端的理解往往就 JavaScript 代码复制粘贴实现 HTML 页面的轮播等功能就完事，只是后端顺手把页面套了是上不了什么台面的技术活。

说起来我也是半路出家，因为那时候我的主要还是写点 PHP 以及 Java 然后再来折腾 HTML 页面。再往后就是入职了淘宝，才对于前端这个职位有个比较系统的认识以及深入。

如果说当时的大环境是 Web2.0 的时代，那么前端这个职位的技术深度其实几乎停留在 Web1.0：大量的非工程化的前端代码四处堆放，没有工程化的概念，前端也忙于四处救火不是套页面就是修复各种因为浏览器兼容性造成的页面错乱等等事情。

总结下来，那时候（2010 年上下）我个人对于前端这个职位的也是迷茫的：一是业界对于前端这个职位的定位非常的模糊，单纯的对于这个职位而言往往只有一二线的大厂有专门的职位，你能跳的公司其实来回也就那么几家；二是个人因为业务的发展承担了更多的职责，如果只是从前端的角度和高度去考虑整个项目的落地和实施情况，往往是非常的片面以及各种不足。

好在那时候移动互联网的兴起，业界的快速迭代让部分的疑惑变成了让业务 push 你走的动力。

就是在那个环境下，我逐渐从前端这个职位切到了移动端，再后来因为团队的成员比例变化从移动端切到了后端以及管理。

其实我现在回想和总结起来，那时候的我还是相对浮躁了些，如果按照我现在想法和逻辑，我肯定不会做以下的几点：

1、对于前端方面我在「前端娱乐圈」的文章中也喷过，我当时也是过于的关注用户界面的展现形式，然后将各种所谓的新技术套用到自己认为很能出彩的地方，然后显得自己非常的有成就感。

2、过多无意义的争论甚至是争辩，因为前端的可实现以及「重复的轮子」太多，所以造成一个问题可以有多种的解决方案。如果不从全局的角度看待或者作出决策，很多时候往往会陷入无谓的孰优孰劣的争论中，非常的没有必要。

3、从前端转移动端以及后面的后端，往往会带着思维的惯性来理解不同技术栈的方案。例如我曾经干过件「蠢事情」就是自己撸了个所谓后端的高灵活性的框架，然而到后面我才知道 IoC 以及 DI 原来 Spring 已经帮你做到了所有你所想的事情。

4、后端其实出成果的路径往往没有前端的直接，前端优化部分的 case 往往用户从体验上来说非常能直观的感受到，而后端如果需要同样的效果需要做更多的事情往往风险也更大。因此，有段时间我从后端的角度上来说，变更极为的保守。

从技术栈上来说，我入后端是从 PHP 开始的，然后写的最长的时间是 Java ，到近几年（ 2019 年开始）才开始写 Golang。

如果您考虑从前端转后端，其实任何种后端语言都应该能够被深入的研究和掌握，但是咱们需要考虑的因素有更多不仅仅是技术栈方面的事情。

首先，从自身角度上来说，我们需要明白自己擅长做什么以及不擅长做什么。了解自己的边界后，从能定位自己的定位。

其次，从大环境来说 Java 技术栈还是主流，相信你掌握 Java 技术栈以后，再去了解其他的后端技术栈也是能一通百通，技多不压身。然后，自己能够足够回答上述的两个问题后，再去做学习上的规划也会明确很多。

还有个想法我其实想提出来，让您多考虑下。

小城市虽然能够提供的职位相对比较少，可能高度也不会很高。但是我们随着年龄的渐长，需要考虑技术方面的问题其实也会越来越少，例如考虑家庭等等的因素。

这点我们得明白自己需要什么，因为环境的制约造成的困扰，其实改变自身来解决是非常困难的，有可能的方式换个思路例如换个环境才是比较好的做法。

以上的观点可能过于主观，仅供参考。