SiG Staff Blog

やっていることをつらつらと

Backlogでpull requestがあった時に、自動で静的解析ツールが走る様にしてみた。

はじめに

会社でチケットベースでの開発 + Git が定着してきて多少なりにモダンな状態になったが、 作業者ごとにレベル差があってレビューの時間が結構かかるのが問題だった。 コーディング規約に沿っているかとか、簡単なバグは静的解析ツールに任せればレビューで見る箇所が減るのでは。 という事で、Jenkinsを使ってCIをする事に。 いつもはphpだけど、今回はjavaで。

やる事

  1. AWSにJenkinsをインストール
  2. Backlogでpull requestがあった時、Jenkinsが色々チェックする。
  3. エラーがあった時、JenkinsからSlackへ通知

とりあえず、これらが出来ればいいかなと。

AWSにJenkinsを準備する

AWSにJenkinsをインストール

f:id:Bee_Flim:20171018152806p:plain

  1. AWSのEC2を適当に作成します。(Amazon Linuxを使用しました)
  2. セキュリティグループで8080ポートにアクセスできるようにインバウンドに追加します。
  3. Backlogのwebhookが取れるように下もインバウンドに追加します。
カスタム TCP ルール TCP 8080 - 9999 54.238.59.48/32
  1. Jenkinsでjavaを使用するのだが、javaが1.7なので1.8をインストールする
    sudo yum -y install java-1.8.0-openjdk-devel
    
    # インストールが行われる
    
    # java1.8をデフォルトにする
    $ sudo alternatives --config java
    2 プログラムがあり 'java' を提供します。
 
    選択       コマンド
    -----------------------------------------------
    *+ 1           /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java
       2           /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.25-0.b18.4.amzn1.x86_64/jre/bin/java
 
    Enter を押して現在の選択 [+] を保持するか、選択番号を入力します:2
  1. java --verson で1.8であることを確認する。
    $ java -version
    openjdk version "1.8.0_25"
    OpenJDK Runtime Environment (build 1.8.0_25-b18)
    OpenJDK 64-Bit Server VM (build 25.25-b02, mixed mode)
  1. jenkinsをインストールする。
    # Jenkinsをダウンロード
    sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
    
    # パッケージ署名チェック用のキーをインポートする
    sudo rpm --import https://jenkins-ci.org/redhat/jenkins-ci.org.key

    # jenkinsのインストール
    sudo yum install jenkins
    
  1. jenkinsを起動する
    sudo service jenkins start
起動されたら、http://public DNS:8080 にアクセスしてjenkinsの画面が立ち上がるのを確認する。
推奨プラグインはインストールしてもらう。
  1. jenkinsの起動設定をする
    sudo chkconfig jenkins on

静的解析に必要なプラグインをJenkinsに入れる。

  • Gradle plugin - gradleを使うため
  • FindBugs Plug-in - バグ解析用
  • PMD Plugin - コードのチェック
  • checkstyle - コーディング規約チェック
  • Violations plugin - 静的レポートの集計表示
  • JaCoCo plugin - コードカバレッジの算出
  • Task Scanner Plug-in - TODOの収集
  • Jenkins Backlog Plugin - backlogのgitにアクセス

これらをインストールしていく。

ちゃんと動かせなかったので

JenkinsとGradleの知識が薄すぎて、上手い事実行する方法がわからず、 考える前に試したいので、Jenkinsでsudo でgradleを実行できるようにします。

sudoをjenkinsに付与

# こんな感じで設定する
sudo visudo

# Defaults !visiblepw
Defaults visiblepw

root    ALL=(ALL:ALL) ALL
jenkins ALL=(ALL) NOPASSWD:ALL

# 再起動
$ service jenkins restart

gradleをインストールする

こんな感じでインストールする。(パスは適当なところを使用してください。)

cd ~
wget -N https://services.gradle.org/distributions/gradle-2.0-all.zip
unzip gradle-2.0-all.zip -d ~/gradle
ln -sfn ~/gradle/gradle-2.0 ~/gradle/latest
printf "export GRADLE_HOME=~/gradle/latest\nexport PATH=\$PATH:\$GRADLE_HOME/bin" > /etc/profile.d/gradle.sh

Jenkinsの準備はこれで終了

これで、取りあえずJenkinsの準備ができた。 次は、backlogのwebhookをとれるようにして、静的解析が行われるようにする。エラーがあればslackに通知をやっていく。


参考サイト

ソースレビューにJetBrainsのUpsourceを使ってみる - PhpStormとの連携

全てをIDEで完結させる。

前回、Upsourceのインストールと実行をしたので 次はPhpStormからレビューの操作が出来るようにしてみる。

プラグインのインストール

  1. PhpStormのSettingを開く。f:id:Bee_Flim:20170927165202j:plain
  2. pluginsを選択して検索にupsourceと入れるとプラグインが表示されるのでインストールする。※画面はインストール済みなのでボタンがアンインストールになっています。f:id:Bee_Flim:20170927165207p:plain
  3. インストールが終わると、Setting -> Tools -> Upsourceが追加されるので、それを選択する。
  4. Server URLに前回設定したサーバーのURLをポート付きで設定する。 f:id:Bee_Flim:20170927165210p:plain

エディタ上からレビューが見れるか確認する

  1. 設定が終わったら、Upsourceでコメントを入れたソースを開くと左側に吹き出しアイコンが表示されるようになります。※アイコンを表示するのに少し時間がかかります。f:id:Bee_Flim:20170927165214p:plain
  2. アイコンをクリックすると、右にレビューの内容が表示されます。
    1. 対応終了のチェックやコメントへの返信なども出来ます。 f:id:Bee_Flim:20170927165218p:plain
  3. PhpStormの下にあるReviewsを選択して検索をすると、f:id:Bee_Flim:20170927165222j:plain
  4. レビューでコメントがある一覧が表示できます。f:id:Bee_Flim:20170927165227p:plain
  5. コメントをクリックすると、そのコメントがある場所に移動できます。f:id:Bee_Flim:20170927165233p:plain

レビューのステータスを変更する

PhpStorm上からReviewのOK/NGの設定も行えるみたい。

  1. Reviewsを開いて検索して、イイネとうーんのアイコンがあるので、それらを押すとf:id:Bee_Flim:20170927165236p:plain
  2. こんな感じにf:id:Bee_Flim:20170927165240p:plain
  3. こんな感じにアイコンが表示され。f:id:Bee_Flim:20170927165245p:plain
  4. Upsourceにもアイコンが表示されてレビューの状態が分かる。f:id:Bee_Flim:20170927165250p:plain

使ってみて

PhpStormで開発のほとんどの作業が出来るようになるので、案件とかで使っていこうと思います。

ソースレビューにJetBrainsのUpsourceを使ってみる - 準備

Upsourceって何につかうの?

VOYAGE GROUPさんがやられているPodcastでJetBrains製品の特集会(?)でそのアプリの存在を知りました。

ajito.fm

どんなツールかというと、GitHubとかでPull Requestした時にコードにコメントとか入れるあの機能を SVNとかGitとかでも使えるようになるアプリです。

初めに聞いた時は、GitHubとかのPR機能を使えば別に要らないんじゃないの?と思っていましたが、

Upsourceを使うと、

  • PhpStormがしてくれる静的解析を行ってくれる。
  • phpDocを見る事が出来る。
  • コードジャンプが出来る。
  • PhpStormと連携して、IDE上でレビューのやり取りが出来る。

これらの事が出来るみたいです。

ちなみに、PhpStormはこちら www.jetbrains.com

PRのレビュー機能だとテキストでしかコードを見れないので、

  • 変更したソースで使用しているメソッドってこれで使い方あってる?
  • この変数定義はどんな感じだったかな?

とか、レビューがとても楽になりそうな予感。PhpStormとの連携も気になる。 しかも、10ユーザーまでは無料で使えるそうです。ヤバい!

という事で試してみました。(Windowsで)

まずはダウンロード

ともあれ、公式サイトでダウンロード www.jetbrains.com

  1. 公式サイトにアクセス。
    f:id:Bee_Flim:20170927165005j:plain
    サイトトップ
  2. プラットフォームに合わせた物をダウンロード。
    f:id:Bee_Flim:20170927165031j:plain
    ダウンロード画面
  3. ZIPを任意のディレクトリに解凍します。
    f:id:Bee_Flim:20170927165039p:plain
    test
  4. binの中に移動してこれらのファイルがある事を確認。
    f:id:Bee_Flim:20170927165043p:plain
    ファイルの確認
  5. デフォルトでは80ポートを使用してサーバーが上がってしまうので、設定を変更します。
    1. ターミナルを起動してbinディレクトリに移動。
    2. コマンドを実行 bash bash upsource.sh configure --listen-port 11111 --base-url http://localhost:11111
      f:id:Bee_Flim:20170927165048p:plain
      設定を変更
  6. 設定の変更が終わったら、立ち上げ。 bash bash upsource.sh start
    f:id:Bee_Flim:20170927165051p:plain
    起動
  7. ブラウザが立ち上がって初期化が始まります。ちょっと時間がかかります。
    f:id:Bee_Flim:20170927165058p:plain
    初期化の画面
  8. 起動が成功すると、こんな画面が表示されます。次にProjectsを押して、プロジェクトを登録していきます。。
    f:id:Bee_Flim:20170927165106j:plain
    Upsourceのトップ
  9. プロジェクトの一覧が出るんですが、最初なので空っぽですね。Create projectを押して登録します。
    f:id:Bee_Flim:20170927165110p:plain
    Projectsの登録
  10. ぐわっといっぱい出てきますが、このタブでは緑の枠の所を設定するだけです。
    1. Project nameに任意の名前を付けて下さい。IDとreviewIDは自動で入ります。
    2. VCSの種類を選んで、Gitとかだったらhostingがどこなのか設定してください。ヌーラボさんのBacklogとかならGenericを選んで、GitのURLをRepositoryに貼ってください。
    3. Authは接続の方法を選んでください。
    4. Test connectionで接続が出来ることを確認。エラーになったら上の設定のどこかが間違っています。
      f:id:Bee_Flim:20170927165114p:plain
      VCSの設定
  11. 次にCode Intelligenceのタブをクリックして Enableにします。JavaScritpとかPHPとか各々の環境に合わせて設定してください。
    f:id:Bee_Flim:20170927165120p:plain
    Intelligenceの設定
  12. Advancedタブを選んで、デフォルトにするブランチ名を入れておくと便利かもしれません。
    f:id:Bee_Flim:20170927165126p:plain
    デフォルトブランチの設定
  13. 登録が終わると、先ほどのVCSのコミットツリーが表示されます。今回はfix/sampe_testをpushしてPRを送りました。
    f:id:Bee_Flim:20170927165131j:plain
    プロジェクトページ
  14. ブランチにマウスを合わせるとReview changesが出るので、その中のCreate reviewをクリックするとレビューが作られます
    f:id:Bee_Flim:20170927165134j:plain
    reviewの作り方
  15. GitHubみたいな感じでコードにレビューを書いていきます。Reviewrsにレビュアーを設定などもここでします。
    f:id:Bee_Flim:20170927165138p:plain
    レビュー画面
  16. 変数やメソッドをクリックするとphpDocを見る事が出来ます。
    f:id:Bee_Flim:20170927165143p:plain
    phpDocの表示
  17. コメントを入れるとこんな感じになります。
    f:id:Bee_Flim:20170927165148p:plain
    コメントの入力
  18. コメントにタグを付ける事も出来ます。バグとかコーディング規約違反とか
    f:id:Bee_Flim:20170927165153p:plain
    指摘のタグもつけれる

サーバーの停止

サーバーを止めたい時はstopを実行 bash bash upsource.sh stop

f:id:Bee_Flim:20170927165255p:plain
サーバーの停止

レビュー環境の構築はこれで完了

これでレビュー環境の構築は終わり。 ダウンロードとか起動に少し時間がかかるだけで、立ち上げること自体は簡単にできてしまいました。

次はIDEとの連携をさせようと思います。

Travis-CIを試してみた

TDDに恋い焦がれて

プログラムを書いてる途中でも安心したいんです。

実務でテスト駆動で開発をしたいと思い、その環境をどんなものにしようかと思いJenkinsを使って試してみたのですが、 自由度は高くて良かったのですが、その代わりに色々と設定があり いずれは他の人にやって貰うためには少し敷居が高すぎだったので、

いまさら感はありますが、巷で話題のTravis-CIを触ってみました。 googleで調べると色々とやり方が書いてあったような、無いような気がしましたが、 とりあえず、シンプルな感じで動かしてみました。

実際にしたこと

  1. GithubTravis-CIのアカウントをとる。
  2. サービスを連携する。
  3. Laravelのプロジェクトを作る。
  4. yamlを作る。
  5. pushする。

これだけでした。 composerのコマンドを叩かないといけないところでちょっと躓きましたが、簡単です。 知ってればすぐ環境できますね。

www.slideshare.net

いずれは

  • developブランチにマージがあった場合は、テスト + 開発にデプロイ
  • masterブランチにマージがあった場合は、テスト + ステージングにデプロイ
  • masterブランチにタグ付けがあった場合はテスト + 本番にデプロイ

という仕組みにしていきたい。

しかし、問題が

会社がヌーラボさんのbacklogを使用しているので、Travis-CIが使えないという罠・・・。 色々とサービス連携するために、Githubに移行してもらいたいな。

別の物

phpstorm、upsource、youtrack、teamcityとJet Brains製品で固めたい欲求もあり。 teamcityをちょっと試してみようかと思います。

これらを使うと、phpstormだけでほとんど完結してしまうので、社内で広めたい。

スクラムガイド2016を読んでみました 2

実際に何するの?

前回は、大体の登場人物を把握したので、日々何をすべきかってのを纏めてみる。

スクラムを全然知らない人がスクラムガイドをよんでこうだろうなぁって思った内容なので、 間違いがあるかと思いますが、ご了承くださいませ。

まずプロジェクト始まった時にするところから

f:id:Bee_Flim:20170626222402j:plain

  1. PO(お客さんとプロジェクトリーダー)が必要な機能や仕様を洗い出して、何かに登録する。細かく。
  2. POがその工数を見積もる。その後、メンバーで工数を見積もる。
  3. ざっくりみんなでガント化する。
  4. チーム内で、毎日する事、手順、単語、成果物に対する考えとかを共有する。
  5. スクラムウォーターフォールの違いを説明する。

一発受注で「ハイ作って」契約だと、こんな感じでやるのが良いのかなと思いました(ので投稿してるときにやってみてます。)

簡単そうですが

ウォーターフォールとか、普通の学生 -> サラリーマンの流れの人の場合、

  • 指示を受けてしか作業を出来ない。
  • 指示を受けたことの作業しかしない。

の人が多いため、「メンバーで工数を見積もる」すらまともにできませんでした。最初。 なので、こんな感じにしました。

  1. 最初はこっちで見積もりとガントを作ってしまいます。
  2. そのあと、見てもらって大丈夫そうか返答をもらいます。
  3. 1時間毎に目標を立てて、50分間作業、10分振り返り(何で遅れたか or はやかったか)。
  4. 次に活かそうね!

後で出てくる「スプリント」を決める際の特訓にもなりますね。

あとは、指示待ちが多いので、「なんか詰まってない?」、「それをどうしたいの?」という方向で聞く。 意思を聞く。

多分、はじめは返事が返ってこないと思うし、向こうにお前が決めるもんだろうってイライラされると思うけど、聞く。 仕様については教えるけど、実装方法については自主性を付けてもらわないと困る、だからしかたない。

煙たがられてもいい

そのうち、自分が選択した方法で進めるという事に意味を感じてもらえると思う。

定例を決めて行こう

f:id:Bee_Flim:20170626222404j:plain

  1. スプリントという単位をチームで決める。(ソフト開発なら1週~2週?)
  2. そのスプリントでどこまでを実装するかをメンバーが決める(POは妥当性だけを確認すればいいかと)
  3. スプリントが終わったら、コミットできたこと、出来なかったことをみんなで出して、何でそうなったか、対策はあるか?とかを話し合う。
  4. 次のスプリントのコミットを考える。

簡単そうですが、これがまた思っているようにできない

その週にどこまでを実装できるかを決める。

困りポイント

  • 希望でしかない
  • 残業前提である

どうしてもガントを守ろうという流れになるので、阻止したい。 最初の見積もり時にこのスケジュールで定時でOKってしたはずなので、19時には帰る流れで出してもらう。

多分、これが現実的にはメンバーからこの条件で出してもらうの難しい(嫌がる)し、昔ながらの上長には怒られると思う。

なもんで、上長には遅れたらスケジュールを延ばせるてもらうとか、そういう手はずをプロジェクト始まる時点で整えておく必要があるかと思います。 自分だけで裏でこっそり球を持っててもいいです。延ばせるようにしておく。

もしくは、即座に後れをキャッチして報告する。今後の見通し込みで。今後このように遅れるので、調整をしてくださいと。

まぁ、頭の固い人相手だと、苦労しますが、出来ないものはできないし、そもそも後でおんなじような報告しないといけないんだし、先にしておいたほうが楽ですよね。多分・・・。

振り返り

困りまポイント

  • そもそもの、原因を追究しないで話が終わってしまう。
  • 一方的な報告だけになって意味が無い。
そもそもの、原因を追究しないで話が終わってしまう。

前者は、取りあえず「何に」かを追求するしかない。(何で?だとただの知識不足って事になってしまう)

  • その詰まりは、俺もしたよ。
  • おれ、そのライブラリ作ったけど・・・。まだpushはしてないけどな!

見ないな話が出たりするようになります。きっと。 この時も、その人が「遅れを責められている」みたいに感じるみたいです。

自分でやるっていった範囲が出来なかったので、そう思うのはしかたないですね。 次のスプリントの際に「自分でやるっていった範囲」が身の丈に合う様にセットしてもらうしかないです。それのせいで遅れが出るとしても。

他の人に、「進んでいたらキャッチアップして助けてあげて」と声をかけましょう。 まぁ、最初はいい顔はあまりしませんがw

一方的な報告だけになって意味が無い。

最初に、みんなにやりたい報告に仕方を言いましょう。 そして、意見を聞く時に個人あてで振ってみましょう。 たぶん、うまくいかないですが orz

振っても意見が出ない時に、俺はこう思うんだけど、どうです?って聞くといいかも。

これらの困りポイントが出る原因が

「リーダーから指示がきて、それをやる」 という、命令系統ができてるって認識があるから起きるんだと思います。

フラットにやるんだよ。って伝えるの難しい。

スクラムの運用の手順は

f:id:Bee_Flim:20170626222406j:plain

やる内容は簡単なんです。 その中身のクオリティをあげるのが難しいというか、 形骸化してしまっている内容を、しっかりとした目的をもってやるというのが大事。

その為には、

個々にチームの一人であるという認識を持ってもらう必要がある

と思いました。実践してみて。

「集まり」ではなく「チーム」。

次は、もう少し大きいスパンでの振り返りと、まとめとか

スクラムガイド2016を読んでみました

スクラムを基礎から学んでみたいそう思った。

なんでスクラムを?

  1. 今行っている会社では、SESや請負開発を主にしているのですが、 相手企業がアジャイル的な開発を進めている場合はそれっぽいことができるのですが、 こちらも、相手企業も体系的にスクラムなどを学んでいるわけではなく、それっぽいものをやっていだけなので、 結局のところ力業で進めてる。
  2. 相手企業に説明する力がないので、向こうの手法に準ずるしかない
  3. そもそも自社がウォーターフォール開発してる・・・(ツライ)

って状況が嫌だ!

という漠然とした理由とともに、、、

いつもの

という、単純に興味持っただけだったりもします。 いや、取り入れれるものならやってみたいので取り入れますよ。

lean-agile.fm

agileradio.github.io

でも、いきなり重たいのをやりたくないから、ガイドを読んでさらっと学んでみよう。

Scramに出てくる人

f:id:Bee_Flim:20170626222353j:plain

ざっと、4種類の人がでてきて、 それぞれを現実世界に照らし合わせると、

f:id:Bee_Flim:20170626222355j:plain

こんな感じ。 スクラムに詳しい人」なんていねーよ

ガイドを読んだうえで、こんな感じかなぁってのを上げてみますが、 間違っている部分があるかもしれません。 LTみたいな感じで暖かく見てください。

ステークホルダーの役割

  • お客様
  • 偉い
  • 成果物をチェックする
  • フィードバックをする

成果物チェックは受け入れテストを実施してもらうということで、よくあるけど フィードバックがほしいってことを言わないといけないですね。

スクラムマスター

  • 随所でアドバイスをくれる人
  • 目標値の妥当性とか、スクラム的かをアドバイス
  • 社外の偉い人にやってもらうのもあり

たぶん、この人が最初いないとスクラムをやっていくの難しい。

プロダクトオーナー

  • 成果物(プロダクト)の責任者
  • WBS(必要な全作業)を洗い出してチケット化
  • チームの作業が楽になる事は全部する
  • 雑用係・・・

たぶん、雑用する人。でも要。 開発とかは本当はしないのがいい立ち位置なんかなぁって思う。

チームメンバー

  • スプリントの目標を立てる
  • 実際の作業をする
  • プロダクトに対して仕様を満たす責任を持つ

開発者であり、仕様決定者という感じかな。

おさらい

f:id:Bee_Flim:20170626222400j:plain

プロジェクトでよくある、

設計者 -> 開発者 -> テスター

って流れではない

ってことをみんなで認識合わせがいりますね。

設計も開発もテストもチームメンバーの1人1人がおこなう

って所が、よくあるの開発現場と一番違う気がする。

具体的には何をするの?

スプリントとかデイリーミーティングとか振り返りとか、色々あるみたいですがそれは次回に。

AIはプログラマの仕事を奪うのか

AIはプログラマの仕事を奪うのか

ディープラーニングやら、自然言語処理やらAIやらニューラルネットワークとかが世間をにぎわして、 Alpha GOがトップ棋士勝利をしたりしてるなか、 将来、人がやる仕事が減るんじゃないかとおじさん連中が騒いている。

本当にそうなのか??

過去に機械が入り、これまでと全く違う手法が生まれた

過去にそんな業界があります。

それは、音楽業界(のリズム)

超絶な技巧で演奏される速いリズム。

でも、リズムマシンサンプラーなどの登場によって今までの技巧ではできない様なリズムや 人には到底演奏できないリズムが作られ、ドラマーのやってることは古いんじゃ?みたいな風潮が流れたとか流れていないとか。

これらの存在はもう一つ大きく変化をもたらしており、全く演奏できない、音楽の知識もない人でも感性だけでリズムを作ることができるようになって これまでの優等生なリズムではない、クールなちょっと悪めのリズムが作られるようになりました。

人では演奏できない様な複雑なリズムもつくられたりしていました。 人がドラムを叩かなくていいとか言われたりもしていたみたいです。

でも、その出来ないと言われたリズムを気合で習得し、 さらに機械では表現しにくい、割り切れないリズムや回り込んでいくリズムの修練度が高くなって、 機械を追い越しているような気がします。

少なくとも、機械のせいで仕事を失ったりしていません。 機械というライバルが出ても、同じことを続けていたのでそういう人は落ちて行ったのかなぁと。

そこそこ出来るは趣味で終わる

わけではないと思う。

これまでは、そこそこ出来る人でも仕事があって、食べていけるぐらいの報酬がもらえていたけど、 AIなりで自動化されることで、その報酬が下がって食べていけなくなるかも。 かといって、AIがその辺の人に弄れるわけではないので、「AIを使ってそこそこの物を作る」人になればいいんだと思う。

新しく出てきたのに負けないぐらいに育つか、 それを使っていくか、 または、それ以外の何かの手を打つか。

これって、別に今まで会社がやってきたことと変わらないんじゃないかなと思ってる。 コンピューターが出てきた時の様に、やり方が大きく変わるかもしれないけど。