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ファイルを取得します。

$ mysqldump --default-character-set=binary -u mysqluser -p blog.whywrite.it > blog.whywrite.it-20160809.sql

新規サーバを立ち上げる

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

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

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

# kusanagi init
# kusanagi provision blog.whywrite.it

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

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

旧サーバにて
$ scp -r /home/kusanagi/blog.whywrite.it/* [email protected]:/home/kusanagi/blog.whywrite.it/
$ scp blog.whywrite.it-20160809.sql [email protected]:

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

新サーバにて
$ ls -l
total 5336
drwxr-xr-x 6 kusanagi kusanagi    4096 Aug  9 23:26 blog.whywrite.it
-rw-r--r-- 1 kusanagi kusanagi 5459018 Aug  9 23:19 blog.whywrite.it.sql-20160809

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

$ mysql -uroot -p blog.whywrite.it < blog.whywrite.it.sql-20160809

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

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

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

# kusanagi ssl --email [email protected] blog.whywrite.it
# kusanagi https redirect
# kusanagi autorenewal on

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

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

# kusanagi configure

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

# kusanagi nginx
# systemctl start mysql
# systemctl enable mysql

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 でレポート環境を用意した結果です)

whywaita% tree -L 1 -a .  [~/git/report]
.
├── .git
├── .gitlab-ci.yml
├── media              # レポートディレクトリ
└── 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 がこちらです。

image: ****/****:latest // 自家製の準備用パッケージ

before_script:
  - perl --version
  - cpanm --installdeps . --force

stages:
  - sqlite3
  - mysql
  - deploy

dev:
  stage: sqlite3
  script:
    - apt-get install -y sqlite3
    - cpanm install DBD::SQLite
    - sqlite3 misc/db/development.db "***" // 初期処理
    - sqlite3 misc/db/development.db "***"
    - sqlite3 misc/db/development.db "***"
    - perl script/development/set_categories.pl
    - perl script/***_web test

production:
  stage: mysql
  script:
    - DEBIAN_FRONTEND=noninteractive apt-get install -y libmysqld-dev mysql-server
    - service mysql start
    - mysql -uroot -e"***" // 初期処理
    - mysql -uroot -e"***"
    - mysql -uroot -e"***"
    - mysql -uroot -e"***"
    - rm -f config/db.json // デプロイ処理
    - mv ./misc/ci/db.json.mysql ./config/db.json
    - perl script/development/set_categories.pl
    - perl script/***_web test

deploy:stg:
  stage: deploy
  when: on_success
  script:
    - cpanm Cinnamon
    - mv ./misc/ci/general.conf.stg ./config/general.conf
    - echo $CI_BUILD_REF_NAME
    - cinnamon staging deploy:update
    - cinnamon staging carton:install
    - cinnamon staging server:restart

deploy:production:
  stage: deploy
  when: on_success
  only:
    - develop
  script:
    - cpanm Cinnamon
    - cinnamon production deploy:update
    - cinnamon production carton:install
    - cinnamon production server:restart

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

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

# config/deploy.pl
use strict;
use warnings;
use Cinnamon::DSL;

set repository  => '[email protected]:***/***.git';
set user        => 'user';
set password    => 'password';

role production => ['example.com'],  {
    deploy_to   => '/home/user/product',
    branch      => 'develop',
};

role staging    => ['example.com'],  {
    deploy_to   => '/home/user/product-stg',
    branch      => $ENV{CI_BUILD_REF_NAME},
};

task deploy  => {
    setup => sub {
        my ($host, @args) = @_;
        my $repository = get('repository');
        my $deploy_to  = get('deploy_to');
        my $branch   = 'origin/' . get('branch');
        remote {
            run "git clone $repository $deploy_to && git checkout -q $branch";
        } $host;
    },
    update => sub {
        my ($host, @args) = @_;
        my $deploy_to = get('deploy_to');
        my $branch   = 'origin/' . get('branch');
        remote {
            run "cd $deploy_to && git fetch origin && git checkout -q $branch && git submodule update --init";
        } $host;
    },
};

task server => {
    start => sub {
        my ($host, @args) = @_;
        my $deploy_to = get('deploy_to');
        remote {
            run "cd $deploy_to && carton exec -- hypnotoad script/***_web";
        } $host;
    },
    stop => sub {
        my ($host, @args) = @_;
        my $deploy_to = get('deploy_to');
        remote {
            run "cd $deploy_to && carton exec -- hypnotoad script/***_web --stop";
        } $host;
    },
    restart => sub {
        my ($host, @args) = @_;
        my $deploy_to = get('deploy_to');
        remote {
            run "cd $deploy_to && carton exec -- hypnotoad script/***_web";
        } $host;
    },
    status => sub {
        my ($host, @args) = @_;
        my $deploy_to = get('deploy_to');
        remote {
            run "ps axuf | grep ***_web";
        } $host;
    },
};

task carton => {
    install => sub {
        my ($host, @args) = @_;
        my $deploy_to = get('deploy_to');
        remote {
            run "cd $deploy_to && carton install";
        } $host;
    },
};

ハマった/工夫した点

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システムを思い出しました。ちょっと面白かったです。

高専カンファ100 in 東京参加してきた! #kosenconf

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

去る2015/12/19,20 に電気通信大学にて開催されていた”高専カンファレンス100 in 東京”に、高専生ではないですが参加&登壇してきました!

(さらに…)