iTranslated by AI
Productivity Weekly (2022-01-05)
Hello. I'm Hirakiba from the Cybozu Inc. Productivity Improvement Team.
Every Wednesday, our Productivity Improvement Team holds an internal meeting called "Productivity Weekly," where we share topics related to improving developer productivity discovered during the week.
This article is a compilation of the topics from that meeting.
This is the 57th issue. Past articles can be found here.
news 📺
GitHub Actions: Changing the search order for self-hosted runners | GitHub Changelog
The behavior for searching for self-hosted runners when executing a job in GitHub Actions has changed. Previously, it searched for runners belonging to the repository, then the Organization, then the Enterprise, in that order. Now, it seems that the first matching runner will execute the job, regardless of its level.
Additionally, this change reportedly allows jobs to be sent to self-hosted runners faster, especially in Organizations or Enterprises with many runners.
I'm not sure exactly how much faster it is, but a reduction in wait time is always welcome.
Update the routing logic based on recent changes by hross · Pull Request #9307 · github/docs
In GitHub Actions, a change was made so that if there are no registered self-hosted runners, the job will now be queued instead of failing immediately.
Previously, if zero self-hosted runners were registered, jobs requiring a self-hosted runner would fail immediately. Therefore, it was necessary to always have at least one runner registered. However, since keeping a runner running all the time incurs costs, there was a technique of using what's called an "offline runner"—one that is registered but not started. You might think this solved the issue, but these offline runners are automatically unregistered by GitHub after a maximum of 60 days, so you had to periodically re-register them.
Now, jobs no longer fail immediately even if no runner is registered; they are placed in a queue[1]. Consequently, you only need to register and start a runner within 24 hours of the job being created.
I couldn't find a mention in the release notes, but based on the Pull Request, this change seems to apply from version 3.3 for GitHub Enterprise Server.
Setting up and maintaining a mechanism to periodically register these offline runners was a hassle, so I'm very happy that it's no longer necessary.
IP ranges Pricing Model - Announcements - CircleCI Discuss
The CircleCI Cloud IP ranges feature that I introduced previously will be officially released on January 28th and provided as a paid option.
The IP ranges feature allows you to limit the IP address range of network traffic originating from your jobs. This makes it easier to allow access to systems that have IP restrictions[2].
Previously, this was available as a preview for paid plan users, but starting January 28th, it will be provided as a paid option for all users. It consumes 450 credits per gigabyte (GB) of traffic for jobs where it is enabled.
Whether 450 credits per GB is considered expensive or cheap varies by individual, but I would like to save on communication costs by taking measures such as moving non-essential parts to separate jobs.
know-how 🎓
Difference Between Editing and Replacing Files, or Safe Replacement of Shell Scripts - mrwk update
This article explains the behavior of overwriting while a shell script is running, which was the cause of the Kyoto University Supercomputer File Loss Incident that caused a stir at the end of last year.
It provides a clear and thorough explanation of the differences between "editing" and "replacing" files in UNIX-like OSs, the mechanism by which accidents occur during shell script editing, and safe overwriting procedures.
To be honest, I didn't understand the difference between editing and replacing at all. It is quite difficult to keep track of the fact that behaviors differ depending on the tool.
Regarding overwriting while a shell script is running, the article "About the behavior of overwriting bash scripts during execution" also provides a detailed explanation. I didn't know that there were execution engines that read and execute shell scripts line by line.
We really need to be careful with file overwrites...
From Agile/DevOps to Developer Productivity ~What the Tabelog Developer Productivity Team Aims for~ - Test Automation
This is an introductory article about the recently established Developer Productivity team at Tabelog. It first explains the history of Developer Productivity Engineering[3] and then introduces the team and its initiatives.
To determine medium- to long-term goals, they are conducting a bottleneck analysis of the development cycle, which seems like a great reference for how to find issues and set goals. They also performed an analysis to achieve the best testing experience, deriving that 10% test automation could reduce 74% of testing man-hours, and actually implemented that automation—a very interesting initiative.
In fact, the team I am in is also a Productivity Improvement team that does various things related to Developer Productivity (as a side note, I felt their activities were slightly more test-oriented compared to our team). It's great to see similar teams increasing in other companies[4]. I'd like to use this as a reference.
Terraform Version 1.1 is now GA | DevelopersIO
This is a Japanese commentary article on Terraform v1.1. It explains the results of trying out various changes and why they are beneficial.
Personally, I thought the moved block was convenient but felt it was a bit awkward to have it remain in the file. However, the following description made sense to me:
For example, what if you were creating a public module and people other than yourself were using it? It would be impossible to tell every user to "use terraform state mv" after refactoring.
For instance, I thought that if you had introduced tfmigrate, you wouldn't need to use moved that aggressively, but I see now there's this kind of benefit when creating modules (though there's also the argument that if a native feature is sufficient, it's better to use the native one).
This is recommended for those who might not have fully understood some features even after reading the English articles on Terraform v1.1.
Afterword
Happy New Year 🎍
I apologize for the very late post. I was living it up by adding some paid leave to the long weekend around Coming of Age Day.
Since the year has started, I'll shake off the post-holiday blues and write the next issue (2022/01/12) as soon as possible.
The Productivity Improvement Team at Cybozu conducts activities to improve the development productivity of our internal engineers. If you're interested in our team, click the link below!
-
Jobs will fail if they remain in the queue for 24 hours. ↩︎
-
I will not discuss the pros and cons of opening holes in private networks here. ↩︎
-
Does this mean Developer Productivity from an engineering perspective? ↩︎
-
Other examples include SWET at DeNA and the Developer Productivity Office at CyberAgent. ↩︎
Discussion