社内の環境を徐々に変えていこうと動き出した話
みなさんこんにちは。ぐーどらです。
前回自社の辛み記事を上げ、やっていき！なことを整理し、一週間取り組んできたことを報告しようと思います。
前回記事↓ guldra-cranch.hatenablog.com
一週間でさらにやったこと
- とりあえずテストコードを更に実装
- 先の記事で上げた手動デプロイでは具体的にどんな作業が発生しているか同僚に聞いた
テストコードを実装
相変わらず続けてます。一通りのページで動作不良を起こしていないか、機械的な正常系テストを書き上げました。
ここからさらに個別のページで使えるよう、便利な動作をしてくれるようなコードを書き上げていけば、日々の業務が楽になるかなと思っています。
先の記事で上げた手動デプロイでは具体的にどんな作業が発生しているか同僚に聞いた
自分の中ではある程度整理できているつもりでしたが、やはり実際に作業をしている人にどんな作業が発生しているかを聞いてみると、更に違った状況が見えてくるものだと思いました。
弊社手動デプロイ苦行3ステップ
- 開発環境とデプロイ先環境の差分比較
- バックアップ取得
- SCPソフトによる手動アップロードや各種コマンド実行
差分比較
開発環境とデプロイ先環境の差分比較自体は必要な作業だと思います。が、ソースコードがコミットされる毎にはレビューを行っておらず、デプロイ前にまとめて差分比較＆確認するという苦行が発生していました。
当然テストコードも存在していないため、SVNにコミットされているソースコードの正当性を誰も保証できていない、けれども目視しアップロードするという作業が発生しています。つらい。
バックアップ取得
社内にあるUSB3.0接続の外付HDに、デプロイ前の環境に配置されていたコードを全てコピーする作業をされていました。
SCPソフトによる手動アップロード＆各種コマンド実行
デプロイ先のパスから、アップロード前のファイル、アップロード前のファイルのパスから大半の確認を経てアップロードが行われます。
どう考えても辛い
考えた解消法
どう考えてもGitHubですね。考えた理由は4つです。
- バックアップ作業が不要になる
- 手動アップロード作業がなくなりワンコマンド化
- プルリクエストで差分比較とコードレビューを行うことでデプロイ前に集中した差分比較を通常業務に組み込むことが可能
- 近況のデファクトとされるCIツールのソースコード管理はGitHubであり、CIツールを使うことで業務フローの改善に繋がる
以上の理由をもって、月曜日に同僚と共にCTOや経営層の説得にかかろうと思います。
自社の辛みが見えてきた話
みなさんこんばんは。ぐーどらです。
6月ですね。1月7日からエンジニアしてるので、まるまる5ヶ月経ったことになります。感慨深い。これくらい働いていると、あれだけいい会社だと思えていた自社にもいくつか不満点が出てくるわけでして、この前ついついTwitterで聞いてみてしまいました。
テストコードが無い職場でcodeceptionの導入をやって、受け入れテストのテストコード書く業務を担当させられるようになった話って需要あります？
— ぐーどらくらんち (@gulDra_cranch) 2019年5月29日
反応もいただき、やはりつらたみは様々な人と共有するといいのかもと思ったので、記事にしていこうと思います。オラワクワクしてきたぞ！
さーて、先週のぐーどらさんは！
- 私だけがテスト書いてどうすんだ
- やはりそのデプロイ先は間違っている
- この素晴らしいAWSに祝福を！
私だけがテスト書いてどうすんだ
前回の記事に経緯を書いたとおり、1人でcodeceptionの導入を行いました。
先週も1人で受け入れテストを書いていました。
そう、1人で。おかげで僕はcodeceptionのSeleniumを使うブラウザテストに対しての知見は少しずつ溜まってきました。が、それは社内に僕1人なのです。
自動テストを運用するようになったとしても、メンテナンスする要員が自分一人になりそうな予感がプンプン…さらに自分自身がテストを書いた経験が豊富ではないことも重なり、（本当にこういうテストでいいのか？）という疑問が常に付き纏っています。
どう実装するのが正解なのかわからないため、プロジェクトにとって有益なテストコードをかけているのか、自社に対して有益なコードを書けているのかとても不安になります。
どうすべきか
とりあえず単体テストと機能テストは諦めました。単体テストはそもそも書けるコードになっていないですし、機能テストはそもそも私自身が書き方がわからないためです。
そのため設定と実行環境を整えられれば簡単に走らせることができるweb driverを使う受け入れテストを書くことにしました。
それだけでも結構バグを見つけられるようになっており、テストやってよかったと実感します。なにより回帰テストの時間=テストコードの実行時間なのもいいですね。
しかし、この状況からテストコードを全員でメンテナンスする文化にする問題は、明らかに自分だけでは解決できない問題なので、まずはコミュニティに頼ることにしました。6/14にYYPHPにお邪魔して、テストに関しての知見を伺おうと思います。
あとは月並みですが、テストに関する書籍やQiitaの記事をあたろうと思います。
あとは現状の1人で実行している状況がまず辛いので、CIツールをプロジェクトに導入してもらえるよう働きかけていきたいと思います。
やはりそのデプロイ先は間違っている
はい、弊社ではCIツールが使われていません。Jenkinsでさえも。
デプロイ方法はscpソフトによる手動です。言語がPHPであるため、静的webサイト感覚でデプロイ出来てしまうのが仇となりました。
走っているプロジェクトは複数ありますが、自社開発ゆえ使われているフレームワークは1つ。つまるところ、複数あるプロジェクトが同じディレクトリ構成で、全く違う内容で同じ名前のファイルが存在したりする環境を手動で選び、デプロイする作業が発生します。
入社当初は2ヶ月くらいはアップロード先が違う！を何回やらかしたことか、、、
あと開発環境からステージング環境、本番環境へのデプロイも手動なの結構笑えません。せめてバージョン管理をSVNからGitにして、マージしません、、、？差分比較も別のツール使わずに、GitのGUIクライアントで出来ますよ…
どうすべきか
CIツールだ。入れさせよう（血眼
CircleCIならSVN使えないから丁度いいと思っているのですが、TravisCIもかなりシェアを握っていると聞いています。CIツールの選定時、何を比較すればいいか詳しい方いらっしゃいましたら、是非教えてください。
この素晴らしいAWSに祝福を！
なんで本番環境のデータベースがEC2インスタンスに構築されたMySQLなんでしょう、、、
その他のサーバーも全てEC2インスタ上に乗せただけなので、多分今やってることを全部ASに載せ替えたら、色々管理してることをAWSが負担してくれるんじゃないかな…と思っています。悲しい。
どうすべきか
AWSに詳しくないので、どこかでどう間違っているという指摘が出来ません。悔しいのですが自分が学習する以外に打開策が思いつかない。学習して〜なメリットがあります！と明確に提示できるようになれば、初めて交渉のステージに立てるようになると思うので、現状は自分の実力不足としか言いようがない。
ですが、AWSインフラに口出し出来るようになれば、他社から見ても魅力的な人材なのでは？を胸に今後も頑張ろうと思います。
今後やっていくこと
- 個人開発でCIツールを使い、いい感じでGitのコミットをトリガーに自動テスト、自動デプロイできるようにする。
- AWS。スコープがでか過ぎるので、まずはデータベースから。せめてS3から学習する。ゴールはもう少し楽に運用できる状態にすること。
幸いなことは、ブラックな会社ではないことで、頭ごなしに「働けーーー！！」ではないところ。
いい感じに緩く、成果で判断される職場なので、今後も緊張感持ってエンジニアやっていきたいと思います。
実績作らなきゃ転職しようにもできませんしね。
Codeceptionを自社のプロジェクトに導入した話
皆さんこんばんは。ぐーどらです。
3月頃からアサインしているテスター業務に4月入社の新卒の女の子をアサインされ、完全に駆け出しってなんもわからんとなっています。
白羽の矢が立つ
部長「codeceptionっていいねぇ。入れてほしいなぁ（チラッチラッ」
噂には聞いていましたし、自社にテストコード無いのは大問題だと思っていたので、codeception入れたいなあと思っていました。まさか本当に駆け出しの自分にテストフレームワークのインストールとコードの記述の仕事が回ってくるとは思っていませんでしたけどね
テストコード書けるのは良い経験になりそうなので、とりあえず頑張る。とりあえずCTOとのやり取りは若干盛ってますが大体そんな感じ。すっげえ雑に振られました。
codeceptionとは
ご存知の方も多いでしょうが、PHPのテストフレームワークです。対応するFWも多く、LaravelやCakeは当然のこと、CodeIgniterやSymfony、Phalconなど、考えうるPHPフレームワークでほぼほぼ動作するテストフレームワークです。
公式はこちら。
やったこと
新卒ちゃんのトレーニングとテスト実行業務とcodeceptionの導入など。駆け出しエンジニアのはずなんだけどどうしてこうなった
WindowsにPHP CLIとcomposerとcodeceptionを入れる
PHPとcomposerはこちらを読んでいただいている方々には今更なんで書きません。Windows環境なので、codeceptionのインストールもcomposer経由が一番簡単そうと感じました。
$ composer require codeception/codeception --dev
（中略）
the requested PHP extension curl is missing from your system
おいまじか
Windowsもう嫌、Docker使えないし、だいたい使うPHP拡張がデフォルトで用意されてないし、そもそもターミナルコマンドがLinuxと違うしetc
（ビルドやんなきゃだめかなあ）と一瞬Windows環境でビルドをするという苦行が頭をよぎりましたが、冷静にphp.iniを覗き、見つけたextension=curlのコメントアウトを外したらcurl有効になりました。公式ありがとう！そして心臓に悪い。
とりあえずPHP Browserでログイン処理を書いてみた
$ ./vendor/bin/codecept bootstrap $ ./vendor/bin/codecept generate:cept acceptance login
cedeceptionで自動生成できる形式にはCept形式とCest形式があるようで、cePtはPlaneで、ceStはSimpleだとか。とりあえずPlaneのほうがより簡素。
# acceptance.suite.yml actor: AcceptanceTester modules: enabled: - PhpBrowser: url: https:(プロジェクトのURL) - \Helper\Acceptance
公式に書いてあったこと丸コピですね。わかります。
// loginCept.php <?php I = new AcceptanceTester($scenario); I->wantTo('ログインテスト'); I->amOnPage('/login'); I->fillField('login_id', '/*プロジェクトで使っているID*/'); I->fillField('password', '/*プロジェクトで使っているパスワード*/'); I->click('ログイン');
とりあえず実行。
$ ./vendor/bin/codecept run Acceptance Tests (1) ------------------------------- ✔ loginCept: ログインテスト ---------------------------------------------------- Time: 1 second, Memory: 10.00Mb OK (1 test, 1 assertions)
めちゃ簡単だった
PHP BrowserではJSで生成されるリンクがクリックできないようなので、ChromeWebDriverを入れ、acceptance.suite.ymlを編集します。
# acceptance.suite.yml modules: enabled: - WebDriver: url: https:(プロジェクトのURL) window_size: false port: 9515 browser: chrome capabilities: "goog:chromeOptions": - \Helper\Acceptance
codecept runで動きました。簡単。
今後やりたいこと
dl要素で生成されているボタンをクリックできるようにする。
チェックボックスを扱えるようにする。
プロジェクトに最適なテストコードを書く
特にプロジェクトに対して最適なコードを書く方法がわからなくて宙に浮いている感じがしています。何かいい本などあったらぜひ教えてください！
Discordで分報を作ってみた話
みなさん初めましての方は初めまして。そうでない方はこんにちは！ぐーどらです。
昨日ProLaboさん主催のもくもく会に参加してきたのですが、6時間近く何故PHPコンテナがビルド直後に落ちてしまうのか原因がわからず、結局近くの人に助けてもらったら5分で解決し、泣きそうになりました。
ここから本題（背景）
先日write-blog-every-week というコミュニティに参加させていただきました。 こちらのコミュニティは1週間に1記事はブログを書き、書けない週が2週間続いた場合は退会というコミュニティです。 心機一転ブログでのアウトプットを習慣化したかったため、参加させていただきました。
さて、私はそちらのコミュニティとは別に、エンジニアの登壇を応援する会というコミュニティにも所属をしていて、そちらでのSlackでは分報というチャンネルを用意しています。 分報の考え方や使い方は、別の方が書かれた記事があるので、私からの説明は割愛します。
気軽に褒め合う文化の醸成された分報は作ってみたい反面、エンジニアの登壇を応援する会ではコミニティへの参加者が300人を超え、Slackのすべての発言が2週間後には消えている状態です。 そのため、分報を作ることに適しているのは本当にSlackなのか？という疑問を持つ人がコミュニティの中で徐々に増え、私自身もその一人でした。
Slackに変わる分報の運用に向いているサービスは無いか考え、一つの答えとしてDiscordを考えました。
何事も実践するのがポリシーな私は、Discordのサーバー機能を使い分報を作り、仲の良い友人間で使ってみたので、いいところ悪いところをシェアしたいと思います。
Discordで感じた不便さ
- POSTに対してスレッドを作れない
- 移行時に記法を覚えるコストが発生する
この2点が大きいところかなと思います。 特に他人の発言からスレッドが伸ばせるところはSlackの大きな利点の一つだなと再確認できました。話題を膨らませられるけれども、パッと見のチャンネル自体には表示されないため、流れを分散させることが出来るところがSlackの利点です。 逆にプレビューが表示されたりといった部分はDiscordもSlackも変わらず可能でした。
新しいサービスを使うことになるので、記法を覚えるコストがかかるというのは当然といえば当然ですが、やはり発生するものだと思いました。
意外に変わらないところ
- 絵文字の使用、追加ができる
エンジニアの登壇を応援する会では、Slackのデフォルトの絵文字に加え、コミュニティで独自に作成した絵文字を使用しています。それに準ずる絵文字を追加する機能はあるの？ということで調べてみましたが、ありました。
ただしSlackとの違いの一つで、Discordはデフォルト時のテーマがダークであり、背景が暗いです。白背景のテーマに設定することもできますが、各々が設定することになるため、両方のテーマで見やすい絵文字にしなければならないというSlackでは考える必要がなかった部分を考慮する必要が出てきます。
Discordの便利なところ
- とにかく通話周りが便利
Discordはゲーマー向けボイス＆テキストチャットを謳っているだけあり、通話が楽です。
今回はサーバー運用していることを前提ですが、サーバーで通話を行う場合はボイスチャンネルを用意し、そこでの参加者間で通話をすることになります。 ボイスチャンネルは常設型で、通話をしたい人がそのチャンネルに入り、終わらせたければ自分がボイスチャンネルから抜けるという非常に気楽に通話が始まり終わる形になります。 さらに音質も非常にいい上、通話全体のマスタ音量だけでなく特定の参加者だけ音量を調節するという小回りも効く作りになっており、通話に関しては大変充実しています。
結論
- DiscordはSlackの代わりではないが便利。通話をしたいのであればDiscordがおすすめ。
- テキストベースでのやり取りはSlackに軍配。スレッド機能はSlackにしか無い。
- テキストの保存上限は現状不明（参加者が3人のみのため、上限に達していない）
上記が結論になります。コミュニティの運営という部分に絞ると、最初から通話してもいいという人は稀かなあという気がしていますので、実際に会うなどの関係性が構築されるまではSlackが最適だなと感じています。 逆に打ち合わせを綿密に行う、声でのやり取りを行うシーンではDiscordに軍配が上がると考えています。伊達に"Skype、TeamSpeakの時代は終わりを告げた…！"なんて煽り文句載せていないなと思いますね。
大人数でのコミュニティでのやり取りに向いた方法ってよくわからないなと思う次第でした。
