てくなべ (tekunabe)

ansible / network / automation

ネットワークエンジニアがはじめてプルリクを出した話(Ansible)



これは DevLOVE Advent Calendar 2018 の 6日目の記事です。



はじめに

DevLOVE のコンセプトは以前は以下の2つでした。

  • 開発の楽しさを発見しよう。広げよう。
  • 開発の現場を前進させよう。

今年は 3つめが追加されました。

  • 自分から越境しよう。

越境とは何なのか、様々な解釈があると思いますが、私としては「何かの意思をもって小さな一歩を踏み出すこと」と考えています。

この記事では私にとって小さな一歩だった、はじめてプルリクエストを出してみたときの話を書きたい思います。


OSSに貢献してみたいけれど

私は、Ansible という OSS の構成管理(自動化)ツールに触ることがあります。OSS に関しては、これまでは利用のみで貢献(コントリビュート)したことがありませんでした。貢献してみたいなと思いつつも、感じていた壁としては以下の 3点です。

  1. GitHub 上のやりとりが英語であること
  2. GitHub の操作そのものが不慣れなこと
  3. コード修正に対する不安感


考え方を変える・協力を得る

前述の3つの壁については、以下のように考え方を変えたり、同僚の協力を得たりしました。

  • 1.の英語については、とある人から「GitHub 上のやりとりで、英語ネイティブの人はそんなにいないよ。」と聞きました。実際のところはどうか分かりませんが、そうなのかもと言い聞かせてチャレンジすることにしました。
  • 2.の GitHub の操作ついては、同僚に練習用のリポジトリを用意してもらって、やりとりを練習しました。Ansible の固有のプロセスについては、The Ansible Development Process というページも参考にしました。
  • 3.については、公式ドキュメントの修正だけでもよいか、と考えを切り替えました。


はじめてのプルリク

公式ドキュメントの簡単な修正から始めてみました。最初は、net_get というモジュール(機能)の説明ページにある、サンプルコード(Playbook)の一行だけです。

本当に一行だけです。

github.com

果たしてマージされるのだろうかと心配でした。ですが、「Ansibleに貢献してみよう」という資料の通り、ドキュメント修正に対するマージは比較的早かったです。 修正ファイルの diff を確認すれば説明不要レベルの修正内容だったので、不安だった英語も何とかなったのだと思います。

説明の書きっぷりについては、他のドキュメント修正のプルリクを参考にしました。

※ 補足 Ansible は、Python のコードに書かれている定型のコメントからドキュメントを生成する仕組みになっています。


マージされてうれしい

マージされたときはとてもうれしかったです。また、Contributor というラベル?が付いたのもうれしかったです。

f:id:akira6592:20181204182428p:plain
Contributor...!

なんとなく雰囲気がつかめたので、ドキュメントの誤りを見つけ次第プルリクを出していきました。簡単な修正だったので、ほとんどはすぐにマージしてもらえました。

ただし、「fix transport option default value of f5 modules docs #44343」というプルリクについては、少し長引いているうちに、needs_rebaseneeds_version タグが付いてしまいました。

f:id:akira6592:20181204182720p:plain
needs_rebase、needs_version タグが付いてしまう

不慣れだった私は「ちょっと通常の状態じゃなくなったぽいぞ・・」と思い、何もできずにそのままにしてしまいました。としばらくすると、別の方が別のプルリクで、私の修正分を良い感じに取り込んでくれました。OSS の優しい世界に触れた気がします。


まとめ

OSSへの貢献への壁はずっと感じてたのですが、ちょっとしたことから始めるのでも全然OKと思いました。 今後もできることから少しずつ進めていきたいと思います。

今回私がやったことは、開発者の方にとっては息をするような簡単なことかと思いますが、ちょっと勇気がいることでした。 逆に「自分では簡単にできても、他の人には難しいこと」というのはある気がします。周りを見渡して、それに気付けるような人でありたいとも思いました。