LINEとSlackを繋ぐline2slack-piperを作りました

この記事はwhywaita Advent Calendar 2016 13日目の記事です。

tl;dr

LINEの会話をSlackに流し込む皆さん向けのプロダクトを作りました。

概要

こんにちは、whywriteit 開発班(この12月から出来た新しい班です!)のwhywaitaです。

tl;drの項目で大体終わっているのですが、とりあえず作りましたのでご報告。

最近某社でインターンを始めまして、その職場でGolangを書き始めたところ楽しくなってしまったのでお勉強用に以前から欲しかったbotを作ってみました。

機能としては、LINE botとして常駐させておいて、botに話しかけるとその結果がSlackに通知されるものです。

line2slack-line

line2slack-slack

LINEの問題点

LINEはそのアカウントの作りやすさから爆発的にユーザを増やし、様々な要因(以前からユーザが多かったSkypeのスマートフォン移植が最初期はとても使いづらかった、等)が相まって、日本では現在も多くのユーザが存在します。
トークを手助けするスタンプの存在だけでなく、お店のアカウントをフォローしておく事でクーポンが受け取れたり、LINEアカウントをプラットフォームとしたゲームアカウント、最近ではLINEアカウントを用いて電子決済を行えるようになるなど、急成長を進めているプロダクトです。

ですが、LINEには問題点が1つあります。複数端末での利用が考えられていない事です。
恐らくですが、アカウントログインがかなり排他的な実装になっており、携帯端末を移行する際も事前に処理を行っていないとトークのログが追えない所か、最悪アカウントにログインすら出来ない事態になってしまい、私の周りでも「携帯が変わったのでLINEのアカウントも変わった」という話がよく聞こえてきます。

現在はPCからログインする事で利便性が少しは高まっていますが、やはり通知能力が異常に低いと言って間違いではないでしょう。

これを解決する為に、近年エンジニア界隈で流行している「Slack」にLINEの会話通知をそのまま通知し、連絡が来ている事に素早く気づけるソリューションを開発しました。

LINE Messaging API

少し前に発表されたLINE Message APIというのを使っています。
以前のAPIと比較して最近はグループに参加させる事も可能なので、ログの保存について難しいLINEにおいてもSlackに投げる事で保存し続ける事が出来ます。
LINE notifyなどでIFTTTを使う事も出来るのですが、どうも相性が悪いらしく、勉強も込めてLINE APIをそのまま叩く事にしました。

問題点(ハマった点)

LINEの設定でグループに入れなかった

今回の新APIの大きな特徴としてグループ会話に参加出来るようになったのですが、何故か招待を行っても参加してこなかったので少し悩みました。
これはLINE Managerの設定を変更することで参加出来るようになっていました。1度参加させる設定にしていたはずなのですが、どうやら外れていたようです。1度確認してみるのをお勧めします。

LINE Manager→アカウント設定→Bot設定→Botのグループトーク参加 を変更する事でグループに参加させる事が出来ました。

LINEには「個人会話」「トーク」「グループ」が存在する

  • 人と人の1:1の通話が「個人会話」
  • 人を集めてから作るのが「トーク」
  • 最初に部屋を作ってから人を募集するのが「グループ」

この違いに最初ハマりました。
最初は私のアカウントとbotアカウントで開発を行っており、上手く行ったのでグループに参加させて遊んでみたのですが、残念ながら動かず…
後でAPIのリファレンスを読んでいて気づいたのですが、この3つは全く別の処理として扱われているようです。
(実はこの辺の処理は公開リポジトリには反映されていません、プライベートな方にはあるのですが、グループIDなどがそのまま書いてあるのでそのまま公開は出来ず…時間が出来たら反映しておきます)

Herokuでgolangを動かす

折角プログラミングという物を始めたので、わざわざサーバを用意せずにHeroku上でやってみました。
Herokuは動作させるコマンドを Procfile というファイルをリポジトリに用意してpushする事でそれが反映されるのですが、最初に以下のように書いていた所動作しませんでした。

それもそのはずで、そもそもHerokuはbuildpackによって生成されたバイナリを起動させます。
Golangはコンパイルした後は1つのバイナリになるため、そのバイナリ名を書く必要がありました。
そのため、以下のように記載する事で上手く動きました。

また、Heroku固有の問題として app.json ファイルの記載がよく分からない事が挙げられますが、これはHerokuの公式ドキュメントを読む事で十分理解する事が出来ました。

グループの誰が発言しているかが分からない

Messaging APIを用いる事でグループにbotを参加させる事ができ、その会話も取得する事が出来るようになったのですが、「どのグループからの通知なのか」は分かっても、「そのグループに参加している誰の発言なのか」は残念ながら分かりませんでした。

この件についてはIssueも上がっているのですが、LINEの方によって全てクローズされており、「この機能を提供する予定は今の所ない」と明言されています。

https://github.com/line/line-bot-sdk-java/issues/40

line2slack-talk

この会話には3人発言しているのですが、残念ながらその3人を区別する術がありません。

まとめ

これでLINEの通知は全て気づけるようになりました。実際にとあるLINEグループで運用されていたのですが、誰が発言しているのか分からない問題が顕著となってしまい、最終的に私の個人slack(と言いながら参加者が20人ぐらい居ますが)のプライベートチャンネルに引っ越す事になりました。

やっぱりSlackは最高ですね。

終わりに

明日のwhywaita Advent Calendarの担当者は…居ません!!!!!!!!!!!!!!!!誰か!!!!!!!!!!!!!!!頼む!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1

Dentoo.LTを引き継いでバトンを渡した話 #dentoolt

この記事はLT Advent Calendar 2016 3日目の記事です。

昨日は id:masawadaさんの4年前、大学でLT大会を始めた – masawadaの日記でした。


こんにちは、whywriteitイベント班のwhywaitaです。
LT Advent Calendarという事で、電気通信大学で開催しているDentoo.LTの主催3名連続でお邪魔させて頂いております。
軽い荒らしのようになっていますね。お気に障った方はすみません。

昨日、masawadaがこのような事を書いていました。

以来、Dentoo.LTは公式に電気通信大学MMAのイベントとなり、回を重ねるにつれ大学の信用を勝ち取り、オープンキャンパスなどでイベントのオファーを頂くまでに成長しました。このあたりの話はid:whywaitaくんが書いてくれるんじゃないかなと期待しています。

実は以前にもDentoo.LTの続け方 – なぜにぽえむという記事を書かせて頂いたのですが、この記事には結果しか書いていなかったので、その過程辺りを書かせて頂こうかと思います。


[ここに様々な前提があったのだがそれを全て検閲削除とする]
こうして、私は大学当局との信頼関係を得る事が出来ました。
信頼を得た後は、その信頼を損なわないよう、またその信頼が更に上がっていくようにシフトしていきました。

信頼を損なわないためには、こちらがやるべき事をちゃんとやる、という事が重要です。一般的に言えば当然至極の事なのですが、これをキッチリやる事に意義がある訳で、後輩の主催者にはしっかり理解して頂けるよう推進しています。

信頼を上げる為には、いくつかの方法がありますが、主に「継続していく」「成果として分かりやすい物を出す」の2つが重要では無いかと考えています。
どんな形であれ継続していく事は大切です。Dentoo.LTは3ヶ月に1回、1年に4回の開催を心がけており、定期的に開催する事で参加者の方の皆さんも予定が立てやすくなり、少しずつ参加者を増やすことが出来ます。
併せて言えば、Dentoo.LTは基本的に日曜日開催を心がけています。大学機関なので平日の方が様々なご担当者の方がいらっしゃるので開催はしやすいのですが、参加者の皆さんが参加しやすいようにと、出来るだけ日曜日開催に出来るよう頑張っています。

継続する事で、成果は分かりやすく出す事が出来ます。
そもそも「何年間継続してイベントが開催されている」という点でも大きな成果ですし、例えば「権威のある〇〇さんが登壇された」や「〇〇人参加者が集まった」などなど、分かりやすい物が生まれてきます。
このような分かりやすい数字は意外と効いてきます。対外的な説明をする際にも色々と言えてかなり便利です。
自分から成果を出そうと躍起になる事はあまりないのですが、ちょっと頑張ってみたり、続けてみたりしてみると自ずと結果がついてくるのではないかと思います。


こういう信頼を得ることで、前述した通りDentoo.LTは大学の行事であるオープンキャンパスの一環として開催したり、学園祭である調布祭の一行事として参加しました。
特にオープンキャンパスは入学を考えている高校生の皆さんが来る場で開催する訳ですから、中々一学生サークルである我々が参加することは難しいのですが、様々な交流の中でオファーを頂き、開催させて頂きました。
その際に参加していた高校生の中で数人は「Dentoo.LTを見て電気通信大学に行く事を決めました」という嬉しい事を言っておいてくれたりします。開催して本当に良かったと感じています。


という訳でバトンを引き取って渡した辺りの話をさせて頂きました。
本当に大変だった部分は私としても是非文章として残したいと以前から思っているのですが、様々な事情があり今回も検閲削除となってしまいました。申し訳ないです。

もし興味のある方がいらっしゃいましたら、恐らく直接であればお話出来るとは思いますので、1度何処かでお声がけ頂けますと幸いです。
(恐らくかなり長くなるので、覚悟してお声がけ下さい)


私はDentoo.LT #13を最後に主催を交代しました。明日の担当は次の主催者(であり現在の主催者)である@benevolent0505 くんです。

電気通信大学に入学してかかるお金を計算してみた #kosen10s

これは#kosen10s Advent Calendar 2日目の記事です。

昨日は@marin72_com#kosen10s の日々のしょうもない日常について.でした。

こんにちは。whywriteit kosen10s班のwhywaitaです。

お前誰だよ

準高専生(@denari01命名)のwhywaitaです。

  • 電気通信大学生
  • 一般高校出身
  • 高専卒業ではない(現在の最終学歴は高卒)

これを見ていると完全に高専生とは関係が無いのですが、色々な縁があり先日 #kosen10s LT5に参加させて頂きました。様子はこちらに纏まっています

この #kosen10s Advent Calendarが公開されて直後に、@marin72_comからDMが届きました。

marin72_com-dm

marin72_com-img

た、確かに〜〜〜関係者って書いてある〜〜〜〜

という訳で2日目にお邪魔しています。

本題

#kosen10s Advent Calendarは特に内容を問わないとの事でしたので、電気通信大学について書きます。

電気通信大学に通学する間にはそれなりにお金がかかります。今回は4年間昼間の学部生として通学した際にどのぐらいお金がかかるか計算してみましょう。

参考資料として大学のページを利用します。

入学金

入学した時に1回かかります。282,000円です。

授業料

半期(半年)毎に1回かかります。267,900円を8回払います(留年などした場合は回数が増えます)。

新入生合宿

新入生として参加します。研修費という名目ですが12,000円かかります。何らかの事情で中止になった場合は大学から返金されます。

学友会

新入生の時に入る(=4年間入る)場合は20,000円かかります。4年生の時に入ると5,000円という事ですね。

学園活動後援会

これも新入生の時に入る場合が多いようです。20,000円かかります。

学生生活総合補償制度(学研災コース)

所謂学研災です。インターンの時などに入っている時が必須な場合があるようで、後から入る人もそれなりに居るようです。4,660円かかります。

生協

電気通信大学には生協がありますが、出資金として16,000円かかります。

合計

という訳で合計2,485,860円かかります。ばばーん。

この額全てを出す必要があるかと言われるとそうではないのですが、個人的には出しておいた方が良いのではないかと考えています。この辺は各個人で良い感じに選択していけば良いと思います。

ちょっと計算

これだけだとつまらないのでちょっと計算してみましょう。

一授業辺りいくら?

私(2013年入学)が卒業までに必要な取得単位数は126単位です。全てが全て授業ではないので正しい計算では無いのですが、概算すると126/8=15.75単位で、半期で16単位ほど取れば良い計算です。

半期で267,900円かかりますので、一授業は16,743.75円のようです。
一授業は15回で構成されているので、1回の授業で1,000円ほどかかっている計算ですね。

自主休講という言葉がありますが、その際には1,000円無駄にしている計算になります。

高専編入勢はいくら?

折角 #kosen10s Advent Calendarなのでそちらも計算してみましょう。
※ここは実際に編入した勢に聞いた訳では無いので想像で計算します

入学金: 282,000円
授業料: 267,900円を4回
学友会: 2年分なので10,000円
学園活動後援会: 20,000円
学生生活総合補償制度(学研災コース): 4,660円
生協: 16,000円

合計: 1,404,260円

通常の学部生と比較して100万円ほど安いようです。やはり授業料が大きいですね〜。

その他

私のように地方から出てきている場合は1人暮らしの為に家賃もかかりますし、実家から通学する場合にも電車代などがかかるのではないかと思います。

昼食を食べるためにお弁当代であったり外食したりをする必要もありそうです。
もしかしたら夕食も大学近辺で食べる事もあるかもしれません。

まとめ

大学生はとってもお金がかかっているので頑張って勉強しましょう。
ついでに折角東京に居るので色々やってみても面白いかもしれません。僕はとっても楽しいです。

高専生の話をするなら、偶然kosenconfが開催される学校に居たので、登壇してそのまま界隈の皆様とのご縁が出来ました。
単純にお金だけでは無い部分での利点も強く感じています。

というわけでざっくり計算してみました。興味のある型は是非電気通信大学にお越しください。

明日

明日の #kosen10s Advent Calendarの担当はルーター芸人こと@puhitakuです。

オープンソースカンファレンス 2016 Tokyo/Fall に参加してきました & LTしてきました #osc16tk

こんにちは。whywriteitイベント参加班のwhywaitaです。

今回オープンソースカンファレンス 2016 Tokyo/Fallに参加してきましたので、参加レポートとなります。

(さらに…)

ConoHa3周年・スマートウォッチプレゼント に当選しました!! #ConoHa

以前行われたConoHa3周年・スマートウォッチプレゼントに応募して、その後応募した事すら完全に忘れていたのですが、なんと当選しました!!!

blaze-conoha

応募者の中で抽選一名にしか当たらない物だったそうで、当選の連絡が来たときはかなり驚きましたが、本当に嬉しい!!!!これからもfitbitとConoHa使います!!!!!!!

余談

後輩に『「運動管理して痩せてくれ!!!!!!」ってやつですか』と言われてしまった。悲しい。

なぜにぶろぐのサーバを移設しました

こんにちは、whywriteitサーバ管理班のwhywaitaです。

この度本ブログ なぜにぶろぐ のサーバ移設を行いましたので、その手順を纏めておきます。
(将来の自分向けのドキュメントともなります…)

環境

前提

  • ドメイン変更無し
  • WordPressなど、各種パスワードの変更なし
  • サーバ1台構成から1台構成へのマイグレーション
  • 移行中に閲覧するアクセスあり
    • ダウンタイム0を目指す
  • 移行中に記事更新などのアクセスはなし

前環境

  • kusanagi Version 7.8.3
  • CentOS7.2

後環境

  • kusanagi Version 7.8.1 (さくらのクラウドアーカイブの為少し古いのです)
  • CentOS Linux release 7.2.1511 (Core)

基本的には同じkusanagi 7系へのマイグレーションとなります。

手順

MySQL ダンプファイルを取得する (旧サーバ)

旧サーバにて mysqldump コマンドを用いてdumpファイルを取得します。

新規サーバを立ち上げる

さくらのクラウドなどで新しいサーバを用意しましょう。

kusanagiコマンドにて初期設定、プロビジョニングする (新サーバ)

kusanagiドキュメント を参照しつつ初期設定を済ませます。

旧サーバのファイルを送る

旧サーバ上にあるWordPress関連ファイルをscpコマンドで送信します。

新サーバにて正常にコピー出来ているか確認しましょう。

MySQL ダンプファイルをリストアする (新サーバ)

kusanagi provision コマンドにてDB自体は既に作成されているので、そのままリストアして問題無いです。

SSL証明書発行 (新サーバ)

kusanagiにはLet’s Encryptを用いてSSL化が簡単にできるような機構が用意されています。利用しましょう。

kusanagiサーバを調整 (新サーバ)

権限設定などが間違っている場合は kusanagi configure が便利です。何か設定したら打つぐらいで良いと思われます。

もしWebサーバ(私の場合Nginx)やDBサーバ(MariaDBサーバ)が立ち上がっていなければ起動しておきましょう。

DNS設定変更

旧サーバから新サーバへ、DNSの向き先を変更します。

自分でホスティングされているDNS権威サーバや、ドメイン取得先のコントロールパネル、DNSホスティングサービスなど、自分が利用しているところで設定を変更して下さい。

表示確認

DNSから新サーバのIPが返ってくるようになったら、旧サーバをシャットダウンし、動作に不調が無いか、表示に不調は無いか確認してみましょう。

もし問題が無ければ、移設は終了です。

終わりに

WordPressの移設で検索すると、レンタルサーバ上で行う物などが多くヒットするため、今回はコマンドライン上で行える物をピックアップしてみました。
今回はkusanagi上での移設でしたが、通常のWordPressやAMIMOTOなどでも適用出来る手順であると考えています。

kusanagi は本当に素晴らしいプロダクトで、毎回さくらのクラウド上で利用させて頂いております(さくらのクラウドも、さくらインターネット様から頂いたクーポンにて運用しております!)。この場を借りて感謝申し上げます。

先日、kusanagi RoD(Runs on Docker)が発表され、今回の更新ではこちらを利用してみようかとも思ったのですが、残念ながらLet’s Encryptの更新にはまだ対応していないとの事で見送りました。もう暫くはさくらのクラウド上にて運用されると思われます。

kusanagiは運用が非常に便利なプロダクトなので、個人的に応援していきたいと思います。

皆様、良いWordPressライフを!

GitLab CIでLaTeXコンパイルをどこでも出来るようにする

こんにちは、whywriteit レポート班のwhywaitaです。

LaTeX環境はWindowsでは少し難があったり、OSXでもEl Capitanではそのままインストール出来ない事態が発生したり、何かと構築/運用に対してハードルが高めです。
また、LaTeXは実際に書きたい文章量に対して組版の為に記載する必要のあるタグが多く、お世辞にも気軽に書ける言語とは言えません。

これらの状況を鑑みて、コンテナ技術であるDockerを用いて、gitとエディタとブラウザさえあればどこでもレポートが生成出来るような環境を作ってみました。

tl;dr

準備

GitLabの構築などは今回は割愛します。GitLab Omnibusを使ってサクッとインストールしてください。

2,3年前はGitLabの構築/運用にかなり苦しい思いをしましたが、最近は非常に簡単に運用できるようになっています。これを機にGitLabに再チャレンジするのも手かも!

レポートリポジトリを作成

レポート毎にリポジトリを分けても良いですが、自分は面倒だったのでほぼ全てのレポートが入っているリポジトリを作成しています。

そして、そのリポジトリのルートディレクトリに以下の2つのファイルを設置しています。

このような感じです。(pre_report.sh でレポート環境を用意した結果です)

レポートを書く

masawada/mics_reportを用いれば、LaTeXコンパイルを非常に簡略化してくれます。
masawada/mics_report は素晴らしいソフトウェアなのですが、ここだけ残念なので、kakakaya/mics_reportの利用を推奨します。
mics_reportの使用方法については、当該リポジトリのREADMEを参照してください。

GitLab CIでコンパイルする

リポジトリにこの.gitlab-ci.ymlを置いて、レポート名を調整してください。
pre_report.sh で第1引数に取ったレポート名をディレクトリパスに指定すればそれで動きます。便利ですね。

TeXファイルが書き上がったら、GitLabにpushしてみましょう。ちゃんと書けていれば、GitLabのビルドが走り、pdfファイルがダウンロード出来るようになります。

サンプルとして、 gitlab.com にリポジトリを用意してみました。実際に動いている様子はこちらでご確認ください。

https://gitlab.com/whywaita/sample-report-ci

終わりに

これによって、どこに居てもLaTeXコンパイルが出来る環境が手に入りました。

今回の技術の想定としては、メインマシンではLaTeX環境が入っていて、そこではmics_reportを手元のマシンで使いつつ、どこか外に行った際に、LaTeX環境の入っていないサブマシンでレポート修正したい!みたいな時に使えるのでは無いかと思います。(実際に筆者はそのようにつかっています)

サンプルリポジトリとして gitlab.com のGitLab CIを用いてレポートを作成しましたが、このSaaSはrunnerが共用になっていて、いつまで経ってもビルドが走らないのであまりお勧めしません。皆さんは自分のGitLabを立てて、自分でrunnerを用意しましょう。

では、良きGitLabライフを!

cloudpack杯 第5回 ICTトラブルシューティングコンテストに学生運営として参加してきました! #ictsc

前回から継続して、「ICTトラブルシューティングコンテスト」(以下トラコン)の運営委員として参加していました。本当なら本会が終わってすぐに書きたかったのですが、特に時間が取れず、先ほど自分としての最後の仕事を終えたので、その節目として書き始めてみます。

トラコンについては、前回の参加レポートと、公式サイトにある今回のレポート記事を読んで頂ければ、どのような雰囲気なのかは掴めるかなと思います。

なにをやったのか

マネジメント

前回はツチノコブログに記事を書かせて頂いたり、LTの司会をさせて頂いたりと、対外的に出させて頂いたのですが、今回はマネジメント関連をかなりさせて頂きました。

所謂リーダー的なポジションに就いて、「どうやれば人は上手く回るんだろう」と試行錯誤しながら、色々と始めたり、上手く行かなかったり、上手く行かなかった時にどう舵取りすれば良いのか分からなくなったり、慣れない事をやっているなあと思いながら何とかやり遂げられたかなと感じています。

トラコンの運営は、営利団体ではなく、自分と一緒に運営するメンバーも、自分が養っている訳ではありません。つまり、お願いした仕事を解決する事がその人の人生で生きていく為の絶対的な条件となる訳では無いのです。
こういうとちょっと大げさかもしれませんが、実際には学生のメンバーですので、大学の課題で作業に取りかかれないなどは容易に起こりえますし、(普段からの勉強も勿論重要ですが)テスト期間には特に全体の作業が止まってしまいます。これはメンバーに作業を強要しても仕方が無いことですし、そもそも良い組織作りとしてあまり褒められる事ではありません。
ここの調整がとても難しかったです。世間の会社的なマネジメント手法とは前提が違ったりして、どうやって進めるか頭を悩ませたり、本を読んだり、大人の方に相談したりました。個人的にはOSSや勉強会のコミュニティのマネジメント手法を若干参考にしてみました。

色々始めてみる

運営参加が2回目という事もあって、使っていたソフトウェアに不都合があったり、より良く進めていくために環境を整えてみたりという事もしました。

例えば、運営学生が、準備の段階から表示する技術ブログを開設してみました。
より運営学生を身近に感じて貰えればと思いましたが、如何だったでしょうか?

また、プロジェクト管理ツールとして、GitHub Issuesを使ってみました。今まではRedmineを用いて行っていたのですが、学生の時からGitHubを用いてのプロジェクトマネジメントをやってみるのは良い事では無いか?という話になり、採用してみました。

技術

技術的にはあまり個人的に新しい事を出来なかったかなというのが少し悔やまれる所です。
先ほど公開した問題解説にも書いたのですが、今回新しく触った技術と言えばSeleniumですかね。

問題を実装するだけであれば非常に簡単だったのですが、トラブルを誘導するためにログを生成する必要があり、その為にはブラウザを直接操作しなければいけませんでした。
その為にSelenium入門してみました。意外とさっくり書けたので良かったです(かなり泥臭い実装になってしまったのですが、恐らくSeleniumの仕様だろうなあと思いながら書きました…)。

ちなみに、利用したSeleniumのコードを先ほどgistに公開してみました。宜しければご参考までに。

終わりに

前述しましたが、昨日(03/31)、出題した全ての問題文、及び、運営学生が求めた回答を含めた解説を公開しました。是非次回参加のご参考に。また、今回悔しい思いをした皆様も、技術力向上に役立てて頂ければ幸いです。

この問題解説を公開した事により、私の第5回ICTトラブルシューティングコンテストに関する作業はほぼ終わりました。長い半年間だったと感じています。
次回についてですが、少し身の振り方を考えようかなと考えています。興味のある方は直接お目にかかった時にでも聞いて下さいませ。

cloudpack杯 第5回 ICTトラブルシューティングコンテスト、お疲れ様でした!!!!

GitLab CIでPerlアプリケーションのテスト/デプロイを自動化する

こんにちは、whywriteit インフラ班のwhywaitaです。

今回とある案件でGitLab CIを用いたCIを行ったので、その手順について記録したいと思います。

概要

  • GitLab CI
    • 途中でバージョンアップが何回か入ったのでバージョンは不定ですが、8.4 〜 8.6系
  • Perl 5.20.3
    • Coro導入の関係でこのバージョンです(詳細は後述)

今回はアプリケーションは他の人が書いており、それのCI部分を担当しておりました。自分はPerlを殆ど触った事が無かったので、その辺も込みでハマった所を書いておきます。

実装した動作

  • 実行用のUNIXユーザをサーバ上に用意し、ホームディレクトリにデプロイ
  • 本番用/検証用で別ドメインを用意する、サーバは同じ
  • developブランチにpushがあると本番用に、それ以外のブランチへのpushやMerge Requestがあると検証用にデプロイを行う

.gitlab-ci.yml

一昔前はGitLab CIはあくまでGitLabとの連携が強い単独のアプリケーションだったのですが、最近のバージョンではGitLabの1つの機能としてGitLab CIが導入されています。
ではそのビルドをどのように有効化するかと言えば、gitリポジトリ内に .gitlab-ci.yml という名前でファイルを追加するだけです。簡単ですね。

一部マスクしていますが、実際に利用している .gitlab-ci.yml がこちらです。

config/deploy.pl に関しては、naoya_ito氏の以下のエントリを参考にして制作しました。

開発メモ#1 : Cinnamon によるデプロイ – naoyaのはてなダイアリー

ハマった/工夫した点

Coroが動かない

デプロイツールとして前記した通りCinnamonを選択したのですが、Cinnamonが依存しているCoroは最新版のPerlでは動かないことを知りました。
moznion氏の以下のエントリを見て頂ければ大体終わりです。これを受けて我々はstandard perl 5.20.3を利用しましたが、各自の環境に合わせた選択を推奨します。

plenv で stableperl を利用するの術 & stableperl の話 – その手の平は尻もつかめるさ

CIでのみTerm::ReadKeyのインストールが失敗する

Dockerコンテナでは実際のシェルではないため、インストールは成功してもPerlモジュールインストールテストで落ちるため、結果的にexit codeが1となり落ちます。
我々は検証環境を用意し、動いている事の確認をした上で cpanm --installdeps . --force する事でCIテストを通しました。
テストの実装は以下にある通りですので、皆様はしっかりと検証した上でご利用ください。

  • https://github.com/jonathanstowe/TermReadKey/tree/master/t

検証環境の作成

Viewを書いていたデザイナーの方がサーバを持っていなかったため、別に検証環境を用意しました。
検証環境といいつつ、あるのはMicroServer1台だけだったので、ディレクトリ分けと内部で使用するポートを切り替えるだけの実装でしたが、綺麗な環境でテスト出来るという事で割と評判は良かったです。

最後に

ビルドの成否やGitLabのpush通知などを全てslackに通知していたのですが、マージ出来るかどうかを機械的に判断し、自動的にデプロイする事でかなり開発は高速化出来たかなと感じています。

結果としてコードを書いていた人達の待ち時間がほぼ0の状態までもっていけた(≒インフラ担当として手でのオペレーションをほぼ行う必要がなくなった)ので、仕事は果たせたかなと。

また、少しCIが楽しくなってきたので、他の第3世代CIと呼ばれるSaaSも試してみました。

リポジトリ

エヴァのMAGIシステムを思い出しました。ちょっと面白かったです。