This article is the entry for the 24th day of Ubiregi Advent Calendar 2020.
If you leave the gem update unattended, the difference will become large and the confirmation work will become difficult. If you carelessly make an update with a breaking change, your application will be broken. I think that I am doing gem update on a daily basis so that it does not happen.
As for the method of gem update itself, I think that there are manual bundle update and Dependabot, but this time I will write a procedure to see the update contents generated by them. I will.
First, let's look at CHENGELOG.
As an example, I think that aws-sdk- ~~~ is a typical gem with small changes and frequent updates.
Even if you don't know the aws gem, you can see that it is updated once every 1-2 days by looking at the following CHANGELOG.
ws-sdk-s3/CHANGELOG.md aws-sdk-ec2/CHANGELOG.md
Frequently, most updates have no effect. In many cases, support is added for functions that are not being used, and minor issues are fixed.
In such a case (assuming that the test is written well), if you can confirm that the test has passed, you can merge it and judge that it is a problem update.
Breaking ChangesThe words Breaking Changes and BREAKING are destructive changes, so if you carelessly upgrade the gem version, the app may be corrupted.
Carefully check the contents of Breaking Changes.
If you end support for rails version 5.0 or lower, compare it with the version you are using.
Example faker/CHANGELOG.md at master · faker-ruby/faker
You need to find out if the modified method is used in your app and fix it if it exists. In some cases, the CI may be down and you may notice it.
There is also a kind CHENGELOG that describes how to fix it, so in that case, fix it according to how to fix it. If there is no way to fix it in CHENGELOG, read it from the issue, commit or Conversation of the corresponding Pull Request and fix it.
If you don't understand the updated contents even if you look at CHENGELOG, go to PR or issue.
CHENGELOG usually has a link to the original PR, so check the description of the PR and the content of the original issue to understand the intent of the change. At this point I can somehow tell if the changes are likely to be relevant to my application, If it is irrelevant, it is judged that there is no effect, and if it is worrisome, it is judged by looking at commits and differences.
If you are doing bundle update all together, it is because you can identify which gem update caused it.
If you do bundle update [gem] for each gem, you know that gem is the cause.
As in the above procedure, look at the CHENGELOG to understand the cause and how to fix it, and correct it.
Example, RuboCop 1.0 has been released-koic's diary https://koic.hatenablog.com/entry/rubocop-1-0-has-been-released
When there is a major update of a gem with many users or a big change Some people write articles, so you can find them by searching.
Occasionally depending on the gem. At that time
Comparing v2.7.0...v2.9.1 · rubocop-hq/rubocop-rails
https://github.com/rubocop-hq/rubocop-rails/compare/v2.7.0...v2.9.1
like
https://github.com/ [user name]/[gem name]/compare/[before version upgrade] ... [after version upgrade]
Check the commit history at.
I remember that some gems had file names like news instead of CHENGELOG.
It is usually CHENGELOG, but you may find it with a different name, so if you look for it, you may find it with a different file name.
However, if there is no CHENGELOG, I think that there is no choice but to look at the PR from the commit list between versions.
Search the gem README and usage articles ・ What kind of gem ・ How to use gem Find out by code-searching how it is used in your app.
Once you understand what kind of gem you are using and how you are using it, check CHENGELOG etc. again to see if it has any effect.
During your research, you may find that your app no longer uses gems.
In such a case, create a separate PR to delete from Gemfile.
I think that what kind of gem is important depends on the application, but in the case of a gem that has a big influence on the function, even if you think that it is okay to look at CHENGELOG etc. in the above procedure, actually check the operation in the local environment or test environment You must to do something before you go on.
You can notice if the test is insufficient and the CI passes involuntarily, or if you make a mistake in checking the changes.
Check the contents of the gem update by checking the above contents diligently or roughly according to the degree of understanding of the gem and the importance and influence of the gem.
When checking for gem updates As far as I can see the `CEHNGELOG, it's just a change like (~~~). `` like ・ How did you grasp the contents of the difference? ・ What kind of difference was it? ・ (In some cases) the result of actually checking the operation Comment and approve the PR.
Rather than silently approving, "I thought it was OK because I understood the confirmation method and the difference like this." I'd like to comment because it makes me feel more comfortable when other people see it.
Ruby/Rails gem update procedure at work --Qiita
[How to check the difference between specific revisions on GitHub --Qiita] (https://qiita.com/bigplants/items/0a31b5cc2290d13edb51)
I was checking the gem update in my own way with the knowledge I saw and heard now. I don't have much chance to hear how other people are checking. If you have a better or better way to do this, please comment.