読者です 読者をやめる 読者になる 読者になる

tyoshikawa1106のブログ

- Force.com Developer Blog -

SFDC:Salesforce Development 2016 - Part 5

salesforce.com Git Bitbucket

今回はBitbucketをつかったSalesforceのプロジェクト管理についてです。Bitbucketにはコミットしてファイルのバージョン管理をする以外にも覚えておきたい便利機能がいくつかあるのでそれも一緒に紹介したいと思います。


ちなみにSalesforceのメタデータ管理についてまとめたPart 4はこちらです。

プロジェクト管理の流れ

Gitリポジトリの作成方法は大丈夫だと思うので、Bitbucketにリポジトリが作られたところから始めます。プロジェクトに途中参加したときのイメージです。
f:id:tyoshikawa1106:20160708170903p:plain

MaventsMateでSalesforceプロジェクトを作成

まずはいつもとおりにプロジェクトを作成します。
f:id:tyoshikawa1106:20160708171601p:plain


この時点ではSalesforceから最新のコードを取得しただけとなります。
f:id:tyoshikawa1106:20160708171737p:plain

Gitリポジトリとの紐付け

ターミナルからGitコマンドで.gitファイルを作成します。

$ git init

f:id:tyoshikawa1106:20160708171935p:plain


続いてBitbucketとの紐付けを行います。

$ git remote add origin git@bitbucket.org:<your app>.git
$ git remote

f:id:tyoshikawa1106:20160708172126p:plain


Bitbucketとの紐付けができたらGitリポジトリ上のファイルを取得します。

$ git fetch origin
$ git reset --hard FETCH_HEAD

f:id:tyoshikawa1106:20160708172304p:plain


.gitignoreファイルを始め、リポジトリ上で管理されたファイル一式を取得できました。
f:id:tyoshikawa1106:20160708172412p:plain:w200


これでプロジェクトへの参加準備が完了です。

Issue(課題)の作成

設定から有効化することでIssue機能が利用できるようになります。これで誰がどのような作業を行うか管理できます。
f:id:tyoshikawa1106:20160708172701p:plain


画面の開発などのタスクはIssueを作成して管理するようにします。
f:id:tyoshikawa1106:20160708173341p:plain


担当者はそのIssueの作業者です。KindはIssueの種類 (バグ / タスクなどの識別)。Priorityは緊急度という感じで管理できます。ファイルを添付することも可能です。場合によっては設計書や打ち合わせのメモを添付することで情報の共有ができます。


Issueを作成すると#1というように識別番号が自動採番されます。
f:id:tyoshikawa1106:20160708173832p:plain

Issueの対応開始

作業開始時には画面右上のメニューで『開く』を選択します。
f:id:tyoshikawa1106:20160708174052p:plain


これによりステータスが『Open』で更新されます。課題一覧画面での作業状況確認に役立ちます。
f:id:tyoshikawa1106:20160708174236p:plain

ブランチの作成

開発をはじめるときブランチを用意します。ブランチ名ですが、Issue名をつけるようにしておくと管理がしやすくなるみたいです。

ブランチ名にissue番号を使う - Qiita


メニューのブランチページから作成できます。
f:id:tyoshikawa1106:20160708175045p:plain


これでIssue毎にブランチを作成して作業を進める準備ができました。
f:id:tyoshikawa1106:20160708175240p:plain

Source Treeの準備

ブランチを作成したらSource Treeから操作できるようにします。まずはSourceTreeを起動してSalesforceプロジェクトをドラッグ&ドロップしてブックマークとして設定します。
f:id:tyoshikawa1106:20160708182129p:plain:w200


次にBitbucketのページの『SorceTreeにチェックアウト』ボタンをクリックします。
f:id:tyoshikawa1106:20160708182351p:plain:w200


これでSourceTreeにブランチをチェックアウトしてコミットやプッシュなどを行えるようになりました。
f:id:tyoshikawa1106:20160708182630p:plain

開発

普通に開発を進めます。
f:id:tyoshikawa1106:20160708184325p:plain

コミットとプッシュ

画面の開発ができたらコミットしてプッシュします。(実際の開発では細かくコミットしますが今回はデモなので省略します。)


uncommited changesを選択します。作業ツリーのところが追加/変更のあったファイル一覧です。
f:id:tyoshikawa1106:20160708184628p:plain


チェックをつけてステージ環境に移行します。
f:id:tyoshikawa1106:20160708184709p:plain:w300


コミットメッセージを入力してコミットします。
f:id:tyoshikawa1106:20160708185013p:plain


コミットが完了したらプッシュを行います。このとき、masterにはプッシュしません。
f:id:tyoshikawa1106:20160708185151p:plain:w200


これでBitbucketのリポジトリにブランチごとプッシュできました。
f:id:tyoshikawa1106:20160708185356p:plain

プルリクエストの作成とコードレビュー

開発が終わったら、masterにマージします。ですがそのままマージするのではなくプルリクエストをつかって対応します。プルリクエスト機能を使えば誰かにレビューしてもらい、問題なければマージされるという流れを作ることが出来ます。
f:id:tyoshikawa1106:20160708185656p:plain


メニューのプルリクエストから作成できます。
f:id:tyoshikawa1106:20160708185931p:plain


ブランチの閉鎖にチェックをつければマージ後に自動でブランチが削除されます。最初そのほうがスッキリしていいかと思っていたのですが、過去の作業ログを残す意味でも削除しない方がいい気がしてきました。


プルリクエスト作成後の画面はこんな感じです。
f:id:tyoshikawa1106:20160708190201p:plain


コードの差分箇所をここで確認できます。
f:id:tyoshikawa1106:20160708190231p:plain


コメントを残してレビュー結果などを相手に伝えることもできます。
f:id:tyoshikawa1106:20160708190409p:plain


特定のファイルに対してコメントすることも可能です。
f:id:tyoshikawa1106:20160708190522p:plain


その場合、このように吹き出しで確認できます。
f:id:tyoshikawa1106:20160708190609p:plain


プルリクエストには却下機能も用意されています。
f:id:tyoshikawa1106:20160708190828p:plain


ですが、却下するとそのプルリクエストは終了してしまいます。コメントをやりとりして指摘事項の修正を続ける場合は却下する必要はありません。


コメントからタスクを作成する機能も用意されています。
f:id:tyoshikawa1106:20160708191521p:plain


レビューの指摘事項等をまとめておくと次のレビュー時に何を確認すればいいか管理しやすくなりそうです。
f:id:tyoshikawa1106:20160708191640p:plain

指摘事項の修正対応と再レビュー

レビューで指摘されたテストクラスの追加を行いコミットまで終わりました。
f:id:tyoshikawa1106:20160708192241p:plain


問題がないことを確認して再度プッシュします。すると先程のプルリクエストに自動で反映されます。
f:id:tyoshikawa1106:20160708192423p:plain


コミット履歴からも確認できます。(レビュー後のコミットで変更された箇所だけの確認もここからできます。)
f:id:tyoshikawa1106:20160708192454p:plain


このように却下しなければレビュー→修正→再レビューという流れで作業を進めることができます。

プルリクエストの承認とマージ

プルリクエストには承認機能がついています。レビューアが複数人いる場合などはここで誰が承認したかを管理できます。
f:id:tyoshikawa1106:20160708193003p:plain

承認者にはチェックがつきます。
f:id:tyoshikawa1106:20160708193051p:plain


レビューアの承認後、マージボタンをクリックしてmasterにマージします。(ここはレビューアの人の作業)
f:id:tyoshikawa1106:20160708193336p:plain


これでmasterブランチに開発内容が反映されました。
f:id:tyoshikawa1106:20160708193502p:plain

f:id:tyoshikawa1106:20160708193542p:plain

Issueのクローズ

マージされ予定していた作業が完了しました。最後にIssueのステータスをクローズにします。
f:id:tyoshikawa1106:20160708193739p:plain

f:id:tyoshikawa1106:20160708193814p:plain


以上がIssueのオープンからクローズまでの流れです。これで作業毎に誰がどのような対応を行ったか記録を残すことができます。またコードレビューを行うことでうっかりミスの発見や、より良い実装方法の共有などを行うことができます。

Git管理とインデント

Apex開発でインデントを指定する際にタブかスペースか人によって違ったりすると思います。Bitbucketのページからコードを確認する際に、タブの場合隙間が少し広く表示されてしまうので個人的にはスペースの方が良さそうかなと思います。

タブの場合

f:id:tyoshikawa1106:20160708194836p:plain

スペースの場合

f:id:tyoshikawa1106:20160708194855p:plain

最後に

こんな流れでSalesforceプロジェクトをGitで管理できると思います。


SalesforceはGit管理と相性が良くないという話もあったと思いますが、DreamforceでSalesforce × Gitに関するセッションがあったり、Bitbucketを開発しているAtlassian社がSalesforce Developers向けにCookbookを公開したりと、Salesforceとバージョン管理についてもいろいろベストプラクティスが検討されているみたいです。


Gitを使ってバージョン管理することで後から不要になったコードをコメントアウトして残す必要もなくなり、メンテナンスがやりやすくなります。またReactやAngular2などビルド作業が必要になる開発では、静的リソース以外にコードを管理できる環境が必須になると思うのですが、Gitリポジトリを用意することでビルド時の設定ファイルなどを管理できるようにもなると思います。


以上、BitbucketをつかったSalesforceのプロジェクト管理についてでした。