Goalist Developers Blog

HRogチャートの開発フロー(バックエンド編)

f:id:suzutt:20170217000629p:plain

こんにちは2ヶ月ぶりの執筆になります。鈴木です。

新卒メンバーが入社し、CTO入倉と2年目エンジニアの飯尾が技術研修をしていまして、 毎日めきめきスキルアップしているようです。

のちのち自分も開発フロー研修をする予定です。 Qiitaをみても意外とIDEのプラグインを含めて使用方法がまとまっていなかったのでブログに書いてみました。

検証済みバージョン

以下のバージョンで検証済みです。

  • OS
    • OS X El Capitan(10.11.5)
  • Eclipse
    • Luna (4.4.2)
  • Java
    • 1.8.0_25
  • Gradle
    • 3.3
  • git
    • 2.4.2

Eclipse プラグインのバージョンです。

  • EGit
    • 3.4.2
  • Buildship: Eclipse Plug-ins for Gradle
    • 1.0.20

開発ツールのインストール

事前に以下のツールをインストールしてください。

  • Eclipse
  • 上記のEclipseプラグイン
  • git
  • Gradle

Gradleは主にプロジェクトの依存ライブラリの解決に使います。

プロジェクトの設定

Github上のリモートリポジトリのクローン

コマンドラインより、Eclipseのワークスペースに設定したディレクトリ上で以下のコマンドを実行します。

git clone https://github.com/xxxxxx/yyyyyy

Eclipseプロジェクト化

IDEの設定はEclipseの設定ファイル(.project, .classpath, .settings/)はコミットしたくないので、 clone後にはプロジェクト直下でコマンドを実行することで、これらのファイルを作成します。

gradle eclipse

賛否両論ありますが、特にクラスパスの設定がGradleの設定ファイル(build.gradle)とEclipseの設定ファイル(.classpath)でダブルメンテになってしまうのが嫌なのでこのようにしています。

Eclipseへのインポート

Eclipseを起動し、

File > Import > General > Exsiting Projects into Workspace

より、該当のプロジェクトをワークスペースにインポートしてください。

もしプロジェクトが認識されないのであれば、Eclipseプロジェクト化されていないので、 「Eclipseプロジェクト化」の手順が実施されているか再度見直してください。

Gradle Natureを追加

EclipseにGradleプロジェクトだと認識させるために以下の手順を実行します。

プロジェクトを右クリック > Configure > Add Gradle Nature

Gradleプロジェクトと認識されないと、build.gradleを元に外部ライブラリをダンロードしたり、それをクラスパスに追加したりしてくれません。

なぜ、そもそもGradleプラグインを使ってプロジェクトを作成しないのかと思ってる人がいましたら、以下のQiita記事がとてもわかりやすかったのでそちらを。。

qiita.com

Gradleプラグインを使ってプロジェクトを作成すると、コンパイルバージョンが1.5になってしまうようです。

Gradle プロジェクトをリフレッシュ

プロジェクトを右クリック > Gradle > Refresh Gradle Project

により、build.gradleの設定にしたがって、外部ライブラリがダウンロードされ、 クラスパスに追加されます。

コンパイルが通ることを確認する

この時点でコンパイルが通るはずです。もしエラーが出ているようであれば手順実施ミスか、そもそものプロジェクトがイケてないので、迷わずプロジェクトメンバーに相談を。

Githubフローに沿った開発

無事コンパイルが通れば、プロジェクトの設定は完了です。 ここからGithubフローに沿って、開発していきます。

流れとしては開発対象の機能をきめて、専用のトピックブランチを作ります。 開発のきりのいいタイミングで add, commit を繰り返し、こまめにGithub上のリモートリポジトリに push します。 フィードバックが欲しい場合や、変更が完了した場合には push 後にブラウザ上からプルリクエストをします。

以下のGithubフローについては以下の日本語訳が参考になります。

GitHub Flow (Japanese translation) · GitHub

トピックブランチの作成

機能ごとにトピックブランチを作成します。

右クリック > Team > Switch to > New branch

名前は開発内容がわかるような名前をつけます

(例)delete-freeplan-message

開発しながら、変更をgitで管理します。

コミット対象のファイルを指定

コミット対象のファイルを指定します。

プロジェクトを右クリック > Team > Add to Index

コミットする

プロジェクトを右クリック > Team > Commit

必ずコメントを入力します。チケット管理している場合はチケット番号もコメントに含めます。後で他の人が変更を追いやすくすることが目的です。

Github上のリモートリポジトリに反映する

プロジェクトを右クリック > Team > Push Branch

変更が完了したら、Github上のリモートリポジトリに変更を反映します。

プルリクエストする

開発が完了した場合や、フィードバックが欲しい場合に、プルリクエストを行います。 ブラウザ上から以下の記事を参考に実行します。

qiita.com

Eclipse上から出来るといいんですけど、そういうプラグインはないみたいですね。

ソースコードレビューを経て、マージ

プルクエストをされた内容をソースコードレビューし、問題がなければマージされます。 指摘があれば修正後、再度プルリクエストを行います。

そして、次の機能開発へ…

無事マージされたら、次の開発へ。
新しくトピックブランチを作成し、繰り返し開発していきます。

まとめ

本当はユニットテストについても作りたかったのですが、書けるほど詳しくないので断念しました。多分勝手に追記するか、次の記事で書きます。 次回投稿時はユニットテストの話か「HRogチャートの開発フロー(フロントエンド編) 」を書こうかなと思っています。

それでは。