The Git warehouse has been built and used for a long time. The simple reason at that time was that Github's private warehouse was not free. Although Github members have been renewed for many years during the period, they are still self built and popular after all. In this way, I use this example of Gitea to see that the date is actually longer than any digital hardware device I use.

The Gitea project at that time was not very mature, and even the CI module did not need to be used with a third-party CI platform. I personally don't like Gitlab's bloated architecture design, so Gitea and Drone CI The collocation of has always been used like this.

Recently, when sorting out the Git repository and code, Gitea was upgraded, It is found that it is already version 1.21, with Gitea Actions 。 So from the perspective of thin system, does it need to replace Drone CI? From my research and use process, the answer is yes.

What are the shortcomings of Drone CI? The main problems are as follows:

First of all, the original Drone CI is an open source project, but it has complete business goals Acquired by Harness In the future, the open source version is not updated in time, which leads to a very simple interface and is far from the Getea interface. Secondly, Drone CI is registered as an application of Gitea, and then communicates with each other through WebHook. This leads to different problems, such as permissions, network latency, caching, and so on. Another point is that with the increase of R&D team members, the granularity of permissions needs to be precisely controlled in many cases. Drone CI has not been able to complete permission control at the global, organization and project levels.

What benefits will be gained by replacing it with Gitea Actions?

The first is the complete product experience. At least the interface and permissions are consistent. Then, Gitia Actions and Github Actions maintain compatibility in configuration, which reduces the workload of yaml, which I originally needed to configure two sets of CIs separately. At the same time, the rich ecology of Github Actions can also be continued on Gitia Actions.

Of course, one thing to note at present is that Gitea Actions is still in the development stage and its functions are not very stable. It may need to be updated at any time. So after switching to Gitea Actions, you need to pay attention to the updated version at any time (but at least from the configuration of my current projects, no major problems have been found).

In general, Drone CI is still a very excellent CI platform, but the passage of time may not be suitable for me at present. I am very grateful for the emotion of Drone CI. After all, it has accompanied me on the road of development day and night.

20230220: Azure has temporarily migrated to the lightweight server of Tencent Cloud due to force majeure. Whether it needs to continue to migrate in the future depends on the situation.

It has been two or three years since the last migration Generally speaking, it will not be so troublesome, but the network environment at home and abroad is getting worse and worse.

In fact, this blog site is also updated by Buddhism. In addition, the natural love for freedom does not want to be filed (in fact, it has been filed earlier, but it has expired), so it has to be moved to another place
If you were in China, the visit would be a little smoother.

Linode used for a long time, then Vultr. In terms of the current network environment, these second tier cloud service providers are
After all, there are too many individual webmasters and "retail investors" who are the key targets of the domestic big brother, and the cost of supervision is too high.

Therefore, we still want to move closer to a relatively large platform service provider this time. At the same time, we would rather spend more to save time and do not want to use domestic products
Your service provider (don't ask me why). So there are three remaining companies: Google's GCP, Amazon's AWS and Microsoft's Azure.

Google is not used because it doesn't want to put eggs in a basket, and AWS's adverse control panel makes people feel whether this is the same planet as us
If it is designed, then the rest can only use Azure, which is not a good problem at all.

The cost of Azure is not cheap, but I hope it is reasonable. There are fewer and fewer people writing blogs now. I hope I can continue to do so.

I sprayed it a few days ago The so-called front-end "entertainment circle" , although a little emotional, it should explain my current attitude in the front circle.

I received a letter from my former colleague last night. Although I have brought a lot of teams and people, I am really embarrassed to remember who you are, but I am really touched that I can still remember not being talented after so many years.

I think it is necessary to continue writing about my own personal transformation process and mentality from the front end. In fact, this topic has been discussed more than once, but in fact, I used to treat this matter as a joke, without a very serious analysis.

I think it's a very good time to talk about this: first, as a summary of my own career, and second, as a reference for everyone, I'm sorry.

If the time goes back to more than ten years ago, the position and responsibilities of the front end position at that time are actually very vague. The understanding of the front end is often completed by copying and pasting JavaScript code to realize the functions such as carousel of HTML pages, but the back end simply sets up the page without any technical work.

I also became a monk halfway, because at that time, I mainly wrote PHP and Java, and then I struggled with HTML pages. Later, after joining Taobao, I had a more systematic understanding and in-depth understanding of the front end position.

If the big environment at that time was the era of Web 2.0, the technical depth of the front end position was almost in Web 1.0: a large number of non engineering front end codes were piled up everywhere, without the concept of engineering, and the front end was busy fighting around, either covering pages or repairing various page disorders caused by browser compatibility.

To sum up, at that time (up and down in 2010), I was also confused about the position of the front end: first, the position of the front end position in the industry was very vague. For this position, only the first and second tier large factories had specialized positions. In fact, there were only a few companies you could jump back and forth; Second, individuals have assumed more responsibilities due to business development. If we only consider the implementation and implementation of the whole project from the perspective and height of the front end, it is often very one-sided and has various shortcomings.

Fortunately, at that time, the rise of mobile Internet and the rapid iteration of the industry turned some doubts into the driving force for business push.

It was in that environment that I gradually switched from the front end to the mobile end, and then switched from the mobile end to the back end and management due to the change in the proportion of team members.

In fact, in retrospect and summary, I was relatively impetuous at that time. If I followed my current ideas and logic, I would certainly not do the following:

1. As for the front end, I also painted in the article "Front end entertainment circle". At that time, I also paid too much attention to the presentation form of the user interface, and then applied various so-called new technologies to what I thought would be brilliant, and then I felt very successful.

2. There are too many meaningless arguments or even arguments. Because there are too many realizable front ends and "repeated wheels", a problem can have multiple solutions. If we do not view or make decisions from the overall perspective, we will often fall into a meaningless debate about which is better or worse, which is very unnecessary.

3. When moving from the front end to the dynamic end and back end, we often understand the solutions of different technology stacks with the inertia of thinking. For example, I once did a "stupid thing", that is, I built a so-called back-end highly flexible framework, but later I learned that IoC and DI have helped you do all the things you want.

4. In fact, the path of the results from the back end is often not as direct as the front end. The case of the front end optimization part is often very intuitive to the user from the experience, while the back end needs to do more things if it needs the same effect, which is often more risky. Therefore, for a while, from the perspective of the backend, the changes were extremely conservative.

In terms of the technology stack, I started with PHP when I entered the backend, and the longest time I wrote it was Java. In recent years (2019), I started to write Golang.

If you consider moving from the front end to the back end, in fact, any back-end language should be able to be studied and mastered in depth, but we need to consider more factors than just the technology stack.

First, from our own perspective, we need to understand what we are good at and what we are not good at. Once you know your own boundaries, you can never position yourself.

Secondly, in terms of the overall environment, the Java technology stack is still the mainstream. I believe that after you master the Java technology stack, you can also learn about other back-end technology stacks. Then, when you can answer the above two questions, it will be clearer to plan your study.

I actually want to put forward another idea for you to consider.

Although small cities can provide relatively few posts, they may not be very high. However, as we grow older, we need to consider fewer technical issues, such as family and other factors.

We need to understand what we need. It is very difficult to change ourselves to solve the problems caused by environmental constraints. It is better to change our thinking in a possible way, such as changing the environment.

The above views may be too subjective and are only for reference.