はてなの金次郎

とあるエンジニアの技術系ブログ

DjangoのINSTALLED_APPSの順番がめちゃくちゃ重要だった話

Django Python Programming

TL;DR

  • INSTALLED_APPS は最初にリストされているアプリケーションのソースコードが優先される
  • INSTALLED_APPS は ローカルアプリケーション・サードパーティアプリケーション・Djangoアプリケーション という順番にしたほうがよい
INSTALLED_APPS = [
    # Local apps
    'polls.apps.PollsConfig',

    # Third party apps
    'rest_framework',

    # Django apps
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
]
  • 上記の順番にするとテンプレートや静的ファイル、マネジメントコマンドを上書きする変更が反映される

INSTALLED_APPS

Djangoの環境変数に INSTALLED_APPS という環境変数があります。

これはDjangoインスタンスの中で有効化されているすべてのDjangoアプリケーションの名前を保持するリストの環境変数です。

django-admin startproject で作成されたDjangoアプリケーションの INSTALLED_APPS はデフォルトで以下のアプリケーションを保持しています。

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

この INSTALLED_APPS を編集するタイミングが主に2パターンあると思います。ひとつは django-admin startapp でローカルアプリケーションを追加した場合。もうひとつはサードパーティのライブラリをインストールした場合です。

django-admin startapp でローカルアプリケーションを作成したら、そのアプリケーションおよびモデルを有効化するために INSTALLED_APPS に追加する必要があります。例えば、 polls というローカルアプリケーションを作成した場合以下のように追加します。

INSTALLED_APPS = [
    ...
    'polls.apps.PollsConfig',
    ...
]

※ ちなみに、単に polls と追加するのはタブーです。

Your code should never access INSTALLED_APPS directly. Use django.apps.apps instead.

FYI: https://docs.djangoproject.com/en/2.1/ref/settings/#installed-apps

また、サードパーティのライブラリをインストールしたら INSTALLED_APPS にアプリケーションを追加する必要がある場合があります。例えば Django REST Frameworkは以下のように rest_framework を追加する必要があります。

INSTALLED_APPS = [
    ...
    'rest_framework',
    ...
]

INSTALLED_APPSの順番

INSTALLED_APPS に関する順番に関しては特に公式ドキュメントには記載されていません。
また、さまざまなサードパーティの README やドキュメント、Djangoに関する記事を見てきましたが本当にバラバラで多種多様です。

私自身も1週間前までは特に順番を意識することなく、Djangoアプリケーション・サードパーティアプリケーション・ローカルアプリケーションの順番でなんとなくまとめているという状況でした。

順番が重要だと気付いたのは、Django管理画面の既存のテンプレートや静的ファイルをカスタマイズしたい・上書きしたいという状況の時でした。ドキュメント通りに変更を加えたつもりが一切変更は反映されなかったのです。

このときはじめて INSTALLED_APPS に関するドキュメントを読んで、最初にリストされるアプリケーションのリソース（テンプレートや静的ファイル、マネジメントコマンド、翻訳）が優先される ということを知りました。

When several applications provide different versions of the same resource (template, static file, management command, translation), the application listed first in INSTALLED_APPS has precedence.

FYI: https://docs.djangoproject.com/en/2.1/ref/settings/#installed-apps

上記の仕様があるため、サードパーティやDjangoの既存のリソースを上書きするような場合、上書きしたリソースがきちんと反映されるためにはそのリソースが含まれるアプリケーション（ローカルアプリケーションであることがほとんどだと思いますが）が上書きしたいリソースのアプリケーション（サードパーティやDjango）より優先されていなければなりません。

つまり、サードパーティやDjangoの既存のリソースを上書きするような場合、以下のような順番にする必要があります。

INSTALLED_APPS = [
    # Local apps
    'polls.apps.PollsConfig',

    # Third party apps
    'rest_framework',

    # Django apps
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
]

最も反映させたいのは言わずもがなローカルアプリケーションです。次にサードパーティアプリケーションです。サードパーティがDjangoのリソースを上書きする場合があるためです。

カスタマイズは必要なくて上書きもしない場合は特にこれを意識する必要はありませんが、私のようにいざそのシチュエーションがきたとき、 INSTALLED_APPS が適切な順番でなかったら変更が反映されず混乱することになります。エラーが何か出力されるわけではないので原因の特定にもかなり苦労しました。

そんなことがないように INSTALLED_APPS の順番には意味があることをぜひ知っておいていただきたいです。余裕があれば自分のプロジェクトの INSTALLED_APPS の順番を見直してみてください。

保守性・可読性の高いPythonコードを実装するためにはどうすればよいか

Django Python Programming

はじめに

コードは理解しやすくなければいけない。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

コードの保守性や可読性を高めるために我々エンジニアはどんなことができるでしょうか？

  • テストを書く
  • 推奨されているコードスタイルに準拠する
  • コメントを書く
  • DRY原則に則る
  • 変更・拡張しやすく設計する
  • ログを出力する・監視する
  • 適切な命名をする
  • etc...

まだまだ意識すべきことはあると思いますが、上記の項目はエンジニアであれば恐らく一度は目にしたことがあるような内容であり、暗黙的に了承されたいルールです。 しかし、これらはただの心構えであり、体現するために実際には以下のような項目に落とし込む必要があります。

  • カバレッジを計測・可視化する
  • コードスタイルを統一する
  • 型チェックする
  • コードのメトリクスを計測する
  • ロガーを設定する
  • etc...

本記事ではこれらの項目をPythonで実践する方法を紹介させていただきます。

カバレッジを計測・可視化する

カバレッジを計測することでユニットテストで実行されたプログラムの割合を知ることができます。 カバレッジが100%であれば、そのプロジェクトにおけるプログラムの全ての行がユニットテストで少なくとも1度は実行されているということを意味します。

有名なプログラマーたちは「テストされていないコードは、壊れているコードだ」と言っています。

独学プログラマー Python言語の基本から仕事のやり方まで

独学プログラマー Python言語の基本から仕事のやり方まで

テストがされていないということは実際の環境でそのプログラムが実行されるまで期待通りに挙動するか確かではないということです。そのようなプロジェクトに一体誰が変更を加えたいと思うでしょうか？

カバレッジを100%にした方がいいということだろうか？したほうがいいじゃない。そうしろといっているんだ。書いたコードはすべてテストしなければいけない。まる。

Clean Coder プロフェッショナルプログラマへの道

Clean Coder プロフェッショナルプログラマへの道

カバレッジを100%で維持し続けるというのは現実的な目標だとは思えませんが、カバレッジが高い水準であるということはソースコードの変更に対するエンジニアの心理的なハードルを下げることにつながります。

結果、サードパーティやOSなどのバージョンアップを迅速に適用できたり、機能追加を行いやすくなったりします。そのためにまず実行するべきはプロジェクトのカバレッジを計測し現状を認識することです。計測した結果、カバレッジが高い水準とは言えない場合にするべき行動は、テストを書き加え、先にテストを書く文化を作ることです。

「テストなんかあとで書けるよ」と言うかもしれない。だが、それは違う。あとで書くことはできないのだ。本当に。あとで書けるテストも少しはあるだろう。注意深く計測していけば、あとでカバレッジ率を高めることもできるだろう。だが、あとで書いたテストは防御なのだ。先に書くテストは攻撃である。あとで書くテストは、コードを書いた人や問題の解決方法を知っている人が書くものだ。こうしたテストは、先に書くテストほど鋭いものではない。

by Clean Coder

Pythonでカバレッジを計測するにはunittestであれば Coverage.py, pytestであれば pytest-cov がよく見かける選択肢ではないかと思います。

Coverage.py

Coverage.pyは、Pythonコードのカバレッジを計測するためのサードパーティです。 テストでコードのどの部分が実行されたのか監視することで、実行されたコードの割合を計測したり実行されていないコードを特定して可視化してくれたりします。

1. インストールする

$ pip install coverage

2. coverage run コマンドでプログラムを実行しデータを集計する

$ coverage run my_program.py arg1 arg2

3. coverage report コマンドで結果をカバレッジレポートをコンソールに出力する

$ coverage report -m
Name                      Stmts   Miss  Cover   Missing
-------------------------------------------------------
my_program.py                20      4    80%   33-35, 39
my_other_module.py           56      6    89%   17-23
-------------------------------------------------------
TOTAL                        76     10    87%

4. coverage html でより詳細なカバレッジレポートをHTMLで出力する

$ coverage html

.coveragerc という設定ファイルにカバレッジを計測しないファイルを指定したり、カバレッジレポートを生成するディレクトリ名を指定したりすることができます。下記はその例です。

[run]
branch = True
source = .

[report]
ignore_errors = True
omit =
  */migrations/*
  */__init__.py
  */const.py
  */tests.py
  */tests/*
  */apps.py
  */manage.py
  */wsgi.py
  */urls.py
  */settings.py

[html]
directory = coverage

pytest-cov

pytestのプラグインでカバレッジを計測するためのサードパーティです。Coverage.pyのオプションはほぼすべてサポートしているようです。

1. インストールする

$ pip install pytest-cov

2. --cov オプションでカバレッジレポートをコンソールに出力する

$ py.test --cov=myproj tests/
-------------------- coverage: ... ---------------------
Name                 Stmts   Miss  Cover
----------------------------------------
myproj/__init__          2      0   100%
myproj/myproj          257     13    94%
myproj/feature4286      94      7    92%
----------------------------------------
TOTAL                  353     20    94%

3. --cov-report=html オプションでより詳細なカバレッジレポートをHTMLで出力する

$ py.test --cov=myproj --cov-report=html tests/

pytest.ini というファイルにpytestのオプションを設定できます。毎回指定するようなオプションはこのファイルに設定しておくと便利です。下記はその例です。

[pytest]
addopts=
  --cov=.
  --cov-report=term-missing
  --cov-config=.coveragerc

カバレッジを可視化する

せっかく計測したカバレッジは可視化しなければ意味がありません。

GitHubであればCI/CDツールやCodecov のようなサービスをうまく活用することでREADMEにカバレッジバッチを追加するとよいと思います。

f:id:gyuuuutan:20181229124915p:plain

GitLabであれば Badges という機能を利用するとカバレッジバッチをプロジェクトのトップページに自動追加してくれます。

f:id:gyuuuutan:20181229125655p:plain

カバレッジレポートを可視化する

ついでにHTMLで出力したカバレッジレポートも可視化しましょう。

https://jumpyoshim.gitlab.io/django-polls/

上記のURLはHTMLで出力されたカバレッジレポートのサンプルです。GitLabPagesに出力されたHTMLをホスティングしています。GitHubであればGitHubPagesを利用するとよいと思います。

このようにカバレッジやカバレッジレポートは誰もがすぐに確認できる状態にしておくとよいでしょう。

ユニットテストの書き方

今回はPythonでのテストの書き方については言及しませんが、わかりやすい参考文献がありますので紹介させていただきます。DjangoCongress JP 2018 で発表されたセッションでtell-kさんによる「できる！Djangoでテスト！」です。

tell-k.github.io

また、こちらの資料でも紹介されていますが、aodag memoの「効果的なunittest - または、callFUTの秘密」は個人的にもとても勉強になったブログです。

コードスタイルを統一する

開発者が同じコーティング規約に準拠していることはとても重要です。統一されたスタイルガイドを利用することはコードの可読性を高めてくれるためです。

Pythonで推奨されるスタイルガイド、コーティング規約についてが PEP8 に記載されています。

例えば、インデントの仕方やモジュールのインポート方法までPythonをコーディングする際に推奨されるお作法がまとめられています。有志で日本語に翻訳されたものが公開されています。

はじめに — pep8-ja 1.0 ドキュメント

また、Pythonのチュートリアルでも簡潔にまとめられています。

4. その他の制御フローツール — Python 3.9.1 ドキュメント

PEP8に準拠しているかどうかをチェックしてくれるツールが flake8 、インポートのスタイルについてチェックしてくれるのが isort です。

flake8

PyFlakes , pycodestyle , Ned Batchelder's McCabe script のラッパーでflake8のコマンドを実行することですべてのツールが実行されます。

1. インストールする

$ pip install flake8

2. flake8コマンドを実行する

ファイルまたはディレクトリを指定することができます。

$ flake8 path/to/code/to/check.py
# or
$ flake8 path/to/code/

また、チェックするルール、無視するルールを指定することもできます。

$ flake8 --select E123,W503 path/to/code/

$ flake8 --ignore E24,W504 path/to/code/

flake8のオプションはsetup.cfg という設定ファイルに設定することもできます。 以下はその例です。

[flake8]
exclude = .git,*migrations*,__init__.py
max-line-length = 100

isort

インポートのスタイルは個人によって癖が出やすい部分ではないでしょうか。isortはインポートをアルファベット順にソートし、自動的にセクションに分割してくれるツールです。

1. インストールする

$ pip install isort

2. isortコマンドを実行する

$ isort -rc .

isortのオプションはflake8と同じく setup.cfg で設定することができます。以下がその例です。

[isort]
line_length = 100
known_django = django
sections = FUTURE,STDLIB,THIRDPARTY,DJANGO,FIRSTPARTY,LOCALFOLDER

また、flake8-isort をインストールするとisortで設定したオプション通りにインポートがソートされているかチェックしてくれます。

型チェックする

変数の型が明示されているとプログラムの理解を助けてくれたり、デバックを容易にしてくれたりします。

Python3.5以上であれば型アノテーション（PEP484）の構文を利用することが可能です。この型アノテーションをチェックしてくれるのが mypy です。

mypy

Pythonの型をチェックしてくれる静的ツールです。PEP484 の型アノテーションが適用されているプログラムをチェックすることができます。

1. インストールする

$ pip install mypy

2. mypyコマンドを実行する

$ mypy program.py

また、型アノテーションを自動生成してくれる PyAnnotate というサードパーティもあるのでうまく活用するとPythonでの静的型付け開発を効率的に行えると思います。

mypy-lang.blogspot.com

コードのメトリクスを計測する

コードのメトリクスとはプログラムの複雑度や行数のことです。これらを計測することでプログラムのどの部分に潜在的なリスクがあるかがわかり、リファクタリングの対象が明確にすることができます。

例えば、以下のようなコードはメトリクスを計測することで指摘されます。

  • 行数が大きすぎる関数やメソッド、クラス
  • 条件分岐が多すぎる制御文
  • ネストが深すぎるコード

いずれもとても読みやすいと言えるようなコードではないことは直感的に理解していただけると思います。 コードのメトリクスを計測することでこういったコードをしっかりと把握できる状態にしておき、適切なリファクタリングをすることで読みやすくメンテナンスがしやすいコードにしましょう。

Pythonプログラムのメトリクスを計測してくれるのが Radon や Xenon です。

Radon

Radonはコメント行や空白行、複雑度などさまざまなコードメトリクスを計測することができるツールです。

1. インストールする

$ pip install radon

2. radonコマンドを実行する

$ radon cc sympy/solvers/solvers.py -a -nc
sympy/solvers/solvers.py
    F 346:0 solve - F
    F 1093:0 _solve - F
    F 1434:0 _solve_system - F
    F 2647:0 unrad - F
    F 110:0 checksol - F
    F 2238:0 _tsolve - F
    F 2482:0 _invert - F
    F 1862:0 solve_linear_system - E
    F 1781:0 minsolve_linear_system - D
    F 1636:0 solve_linear - D
    F 2382:0 nsolve - C

11 blocks (classes, functions, methods) analyzed.
Average complexity: F (61.0)

上記のように実行することで問題があるブロックと平均ランクを出力してくれます。

qiita.com

オプションやランクについては上記の記事がとてもよくまとまっています。

Xenon

Xenon (キセノン) は Radon をベースとしているコードメトリクスの計測ツールですが、 要求に満たない結果だった場合に失敗（ non-zero を出力 ）します。これの何がよいかというと、CIで Xenon を実行するように設定することで強制的にリファクタリングの機会を提供することができます。

コードメトリクスによるより厳密なリファクタリング文化を醸成したいときには Xenon を利用するとよいかもしれません。

1. インストールする

$ pip install xenon

2. xenonコマンドを実行する

$ xenon --max-absolute B --max-modules A --max-average A

--max-absolute はブロックに対する絶対しきい値、 --max-modules はモジュールに対するしきい値、 --max-average は平均複雑度のしきい値を設定できるオプションです。指定されたランクより低い箇所がひとつでもあった場合、 non-zero を返却します。

ロガーを設定する

障害が発生した際にその原因を素早く追及できることは保守性を高める上では欠かせない要素の一つです。 障害発生の調査をしやすくするためには適切な ログ出力 と エラー通知 がされていることが重要です。

エラー通知に関しては Datadogや、AWSであれば CloudWatch 、GCPであれば Stackdriver などの監視ツールを利用する必要があり、Pythonの責務からは離れているので今回は割愛させていただきます。

Pythonでログ出力をするために便利なのが logging というPythonプログラム内で起きたイベントを記録するための標準ライブラリです。

logging

logging はあるプログラムが実行されているときに起こったイベントを追跡するための手段です。イベントにはメッセージやロガーレベル、日時などを含めることができます。

loggingを利用するにあたって理解しておきたいのはロガー、ハンドラ、フィルタ、フォーマッタの役割です。

ロガーは、アプリケーションコードが直接使うインタフェースを公開します。
ハンドラは、(ロガーによって生成された) ログ記録を適切な送信先に送ります。
フィルタは、どのログ記録を出力するかを決定する、きめ細かい機能を提供します。
フォーマッタは、ログ記録が最終的に出力されるレイアウトを指定します。

参考: https://docs.python.org/ja/3/howto/logging.html#advanced-logging-tutorial

1. ロガーを作成する

import logging

logger = logging.getLogger('simple_example')

2. ハンドラを作成する

handler = logging.StreamHandler()

3. フィルタを作成する

logger.setLevel(logging.INFO)
handler.setLevel(logging.INFO)

4. フォーマッタを作成してハンドラに追加する

formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s')
handler.setFormatter(formatter)

5. ハンドラをロガーに追加する

logger.addHandler(handler)

6. ログを出力する

logger.debug('debug message') # 何も出力されない
logger.info('info message') # 2019-01-08 12:18:45,965 - simple_example - INFO - info message
logger.warning('warning message') # 2019-01-08 12:18:45,967 - simple_example - WARNING - warning message
logger.error('error message') # 2019-01-08 12:18:45,968 - simple_example - ERROR - error message
logger.critical('critical message') # 2019-01-08 12:18:45,971 - simple_example - CRITICAL - critical message

上記の方法以外にもロガー、ハンドラ、フィルタ、フォーマッタの設定方法があります。今回は1の方法を紹介しています。

  1. 上述の設定メソッドを呼び出す Python コードを明示的に使って、ロガー、ハンドラ、そしてフォーマッタを生成する。
  2. ロギング設定ファイルを作り、それを fileConfig() 関数を使って読み込む。
  3. 設定情報の辞書を作り、それを dictConfig() 関数に渡す。

参考：https://docs.python.org/ja/3/howto/logging.html#configuring-logging

Djangoを利用する場合は LOGGING という環境変数にロガー、ハンドラ、フィルタ、フォーマッタの設定ができます。以下はその例です。

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'formatters': {
        'simple': {
            'format': '%(asctime)s - %(name)s - %(levelname)s - %(message)s'
        }
    },
    'handlers': {
        'console': {
            'level': 'DEBUG',
            'class': 'logging.StreamHandler',
            'formatter': 'simple'
        },
    },
    'loggers': {
        '': {
            'handlers': ['console'],
            'level': 'INFO',
            'propagate': True,
        },
    },
}

参考：https://docs.djangoproject.com/ja/2.1/topics/logging/

上記の参考文献はDjango公式ドキュメントのロギングに関するページですが、「クイックロギング入門」という章はロギングに関してとてもわかりやすくまとまっています。Djangoが知らなくても読める章なのでぜひ一度目を通してみてください。

おわりに

Coverage.py, pytest-cov, flake8, isort, mypy, Radon, Xenon, logging といったライブラリを活用して保守性・可読性が高いPythonコードが実装できないか模索してみました。（Django成分がやや多めになってしまいました。すみません。）

これらは決して保守性・可読性が高いPythonコードを実装するためのベストプラクティスというわけではなく、およそ2年間Pythonともがき苦しんできた1プログラマの血と涙の結晶だと思っていただければ幸いです。

また、少し触れている章もありましたが、これらはCIで実行することでよりその効果を得ることができます。むしろCIで実行しなければあまり意味がありません。継続的に実行し続ける仕組みが重要です。

「他にもこういう方法がある」とか「ここは違うんじゃない？」といった意見があればぜひご教授ください！

最後になりましたが、これらのノウハウが習得できたのは優秀なチームメンバーのおかげです。ありがとうございます！

Dependencies.ioによるGitLabプロジェクトのマニフェスト自動アップデート

GitLab SRE Programming

はじめに

GitLab Advent Calendar 2018の15日目の記事です。

qiita.com

みなさんマニフェスト（ package.json, composer.json, requirements.txt, etc.）のアップデートはどうされていますか？

気まぐれなタイミングで行なっていたり、手作業で行なっていたりしないでしょうか？

通常運用中のシステムに人手が必要なら、それはバグだ。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

  • 発売日: 2017/08/12
  • メディア: 単行本（ソフトカバー）

５章の「トイル（労苦）の撲滅」での一節です。

  • 手作業であること
  • 繰り返されること
  • 自動化できること
  • 戦術的であること
  • 長期的な価値を持たないこと
  • サービスの成長に対して O(n) であること

上記の項目に当てはまるようなタスクは可能な限り自動化していこうというのがSREの考え方です。
マニフェストのアップデートはまさにこれに当てはまるのではないかと思います。

本記事は、GitLabプロジェクトにおけるマニフェストのアップデートというトイルを Dependencies.io というサービスを利用して撲滅していこうという内容です。

www.dependencies.io

導入方法

導入はお手軽2ステップです。とても簡単に導入することができます。

  1. dependencies.yml をリポジトリに追加する
  2. 対象リポジトリを Dependencies.io に追加する

だけです。

実践

下記の requirements.txt のアップデートの設定をしてみます。

requests==2.20.0
Django==2.1

アップデートのMRが作成されることを確認するためにわざと最新ではないバージョンを指定しています。

1. dependencies.ymlをリポジトリに追加する

f:id:gyuuuutan:20181219022459p:plain

2. GitLabのPersonal Access Tokenを発行する

スコープは api, read_repository を選択します。

f:id:gyuuuutan:20181219021222p:plain

3. GitLabプロジェクトを選択する

f:id:gyuuuutan:20181219021048p:plain

4. 対象リポジトリのURLと発行したPersonal Access Tokenを入力する

f:id:gyuuuutan:20181219021627p:plain

上記で設定は完了です。GitLabのMRを確認してみると...

f:id:gyuuuutan:20181219022757p:plain

確かにアップデートのMRが自動生成されています！

ちなみにDependencies.ioのプロジェクトページはこんな感じです。

f:id:gyuuuutan:20181219022741p:plain

Dependencies.ioの何がいいのか

Dependencies.ioの特徴をまとめてみました。

ワークフローにあったアップデート

複数言語のアップデートが可能

1つのリポジトリで複数の開発言語を利用しているケースがあるかもしれません。そういった場合でも1つの言語だけでなく、複数の開発言語をアップデートするように設定することができます。2018年12月時点で JavaScript, Python, PHP, Docker, Git に対応しており, Ruby, Java, Go, Rust, iOS, Android, .NET に関しても順次追加予定らしいです。

カスタムスクリプト実行後のアップデートが可能

リポジトリによってはカスタムスクリプトやあるコマンドを実行した後にパッケージのアップデートを行いたいといったケースがあるかもしれません。そういった場合でもアップデート前に任意のコマンドを実行するように設定することができます。

上記のように様々なワークフローに対応することができます。

アップデートのカスタマイズ

パッケージ管理ファイルの場所に依存しない

パッケージ管理ファイルのパスを指定できるため、必ずしもトップディレクトリに配置する必要はありません。

バージョンのフィルタリングが可能

フィルタリングという機能を利用すると、必要な更新と依存関係を正確に指定することができます。これにより、いくつかの依存関係をパッチやバグ修正だけに制限することができます。例えば、 L.Y.Y と指定するとマイナーとパッチのバージョンだけ受け入れられて、メジャーバージョンはロックされます。また、 バージョンといってもセマンティックバージョンが全てではありません。正規表現に対応しているため nighly のように指定することも可能です。

パイプラインが自動で走る

GitLab CI/CDのパイプラインを実行してくれるため、テストジョブが設定されている場合、アップデートされたバージョンで確かにテストが通ったことを確認することができます。

ロックファイルの自動アップデート

マニフェストだけではなく、ロックファイルの依存関係もアップデートするように設定することが可能です。

スケジューリング

アップデートの頻度・時間帯の指定が可能

毎日、毎週、毎月のスケジュールオプションにより、プロジェクトや開発チームにあったタイミングでアップデートを受け取ることができます。時間帯の指定も可能です。

おわりに

Freeプランはパブリックリポジトリのみなので、プライベートリポジトリでDependencies.ioを利用する場合は有料プランに加入する必要がありますが、それにしても無料でここまでできてしまうのはなかなかのものではないでしょうか。

導入前の調査でGreenkeeperやDependabot, Renovateなどの類似サービスも候補に上がっていたのですが、GitLabに対応していることがホームページのトップで確認できたのがDependencies.ioだけだったので今回はDependencies.ioを試してみました。

www.slideshare.net

記事を書いたあとにTeppei SatoさんのSlideShareをみてRenovateがGitLabに対応しているらしいことを知り、確認してみたところ確かにGitLabに対応していました。 オートマージなど、機能的にはRenovateの方が充実してそうな印象を持ったのでこちらもいつか試してみたいです。

GitLabに関する機能や豆知識を7つ厳選してみました。
もしよろしければのぞいてみてください。

qiita.com