今回はBitbucketをつかったSalesforceのプロジェクト管理についてです。Bitbucketにはコミットしてファイルのバージョン管理をする以外にも覚えておきたい便利機能がいくつかあるのでそれも一緒に紹介したいと思います。
ちなみにSalesforceのメタデータ管理についてまとめたPart 4はこちらです。
プロジェクト管理の流れ
Gitリポジトリの作成方法は大丈夫だと思うので、Bitbucketにリポジトリが作られたところから始めます。プロジェクトに途中参加したときのイメージです。
MaventsMateでSalesforceプロジェクトを作成
まずはいつもとおりにプロジェクトを作成します。
この時点ではSalesforceから最新のコードを取得しただけとなります。
Gitリポジトリとの紐付け
ターミナルからGitコマンドで.gitファイルを作成します。
$ git init
続いてBitbucketとの紐付けを行います。
$ git remote add origin git@bitbucket.org:<your app>.git $ git remote
Bitbucketとの紐付けができたらGitリポジトリ上のファイルを取得します。
$ git fetch origin $ git reset --hard FETCH_HEAD
.gitignoreファイルを始め、リポジトリ上で管理されたファイル一式を取得できました。
これでプロジェクトへの参加準備が完了です。
Issue(課題)の作成
設定から有効化することでIssue機能が利用できるようになります。これで誰がどのような作業を行うか管理できます。
画面の開発などのタスクはIssueを作成して管理するようにします。
担当者はそのIssueの作業者です。KindはIssueの種類 (バグ / タスクなどの識別)。Priorityは緊急度という感じで管理できます。ファイルを添付することも可能です。場合によっては設計書や打ち合わせのメモを添付することで情報の共有ができます。
Issueを作成すると#1というように識別番号が自動採番されます。
Issueの対応開始
作業開始時には画面右上のメニューで『開く』を選択します。
これによりステータスが『Open』で更新されます。課題一覧画面での作業状況確認に役立ちます。
ブランチの作成
開発をはじめるときブランチを用意します。ブランチ名ですが、Issue名をつけるようにしておくと管理がしやすくなるみたいです。
メニューのブランチページから作成できます。
これでIssue毎にブランチを作成して作業を進める準備ができました。
Source Treeの準備
ブランチを作成したらSource Treeから操作できるようにします。まずはSourceTreeを起動してSalesforceプロジェクトをドラッグ&ドロップしてブックマークとして設定します。
次にBitbucketのページの『SorceTreeにチェックアウト』ボタンをクリックします。
これでSourceTreeにブランチをチェックアウトしてコミットやプッシュなどを行えるようになりました。
開発
普通に開発を進めます。
コミットとプッシュ
画面の開発ができたらコミットしてプッシュします。(実際の開発では細かくコミットしますが今回はデモなので省略します。)
uncommited changesを選択します。作業ツリーのところが追加/変更のあったファイル一覧です。
チェックをつけてステージ環境に移行します。
コミットメッセージを入力してコミットします。
コミットが完了したらプッシュを行います。このとき、masterにはプッシュしません。
これでBitbucketのリポジトリにブランチごとプッシュできました。
プルリクエストの作成とコードレビュー
開発が終わったら、masterにマージします。ですがそのままマージするのではなくプルリクエストをつかって対応します。プルリクエスト機能を使えば誰かにレビューしてもらい、問題なければマージされるという流れを作ることが出来ます。
メニューのプルリクエストから作成できます。
ブランチの閉鎖にチェックをつければマージ後に自動でブランチが削除されます。最初そのほうがスッキリしていいかと思っていたのですが、過去の作業ログを残す意味でも削除しない方がいい気がしてきました。
プルリクエスト作成後の画面はこんな感じです。
コードの差分箇所をここで確認できます。
コメントを残してレビュー結果などを相手に伝えることもできます。
特定のファイルに対してコメントすることも可能です。
その場合、このように吹き出しで確認できます。
プルリクエストには却下機能も用意されています。
ですが、却下するとそのプルリクエストは終了してしまいます。コメントをやりとりして指摘事項の修正を続ける場合は却下する必要はありません。
コメントからタスクを作成する機能も用意されています。
レビューの指摘事項等をまとめておくと次のレビュー時に何を確認すればいいか管理しやすくなりそうです。
指摘事項の修正対応と再レビュー
レビューで指摘されたテストクラスの追加を行いコミットまで終わりました。
問題がないことを確認して再度プッシュします。すると先程のプルリクエストに自動で反映されます。
コミット履歴からも確認できます。(レビュー後のコミットで変更された箇所だけの確認もここからできます。)
このように却下しなければレビュー→修正→再レビューという流れで作業を進めることができます。
プルリクエストの承認とマージ
プルリクエストには承認機能がついています。レビューアが複数人いる場合などはここで誰が承認したかを管理できます。
承認者にはチェックがつきます。
レビューアの承認後、マージボタンをクリックしてmasterにマージします。(ここはレビューアの人の作業)
これでmasterブランチに開発内容が反映されました。
Issueのクローズ
マージされ予定していた作業が完了しました。最後にIssueのステータスをクローズにします。
以上がIssueのオープンからクローズまでの流れです。これで作業毎に誰がどのような対応を行ったか記録を残すことができます。またコードレビューを行うことでうっかりミスの発見や、より良い実装方法の共有などを行うことができます。
Git管理とインデント
Apex開発でインデントを指定する際にタブかスペースか人によって違ったりすると思います。Bitbucketのページからコードを確認する際に、タブの場合隙間が少し広く表示されてしまうので個人的にはスペースの方が良さそうかなと思います。
タブの場合
スペースの場合
最後に
こんな流れでSalesforceプロジェクトをGitで管理できると思います。
SalesforceはGit管理と相性が良くないという話もあったと思いますが、DreamforceでSalesforce × Gitに関するセッションがあったり、Bitbucketを開発しているAtlassian社がSalesforce Developers向けにCookbookを公開したりと、Salesforceとバージョン管理についてもいろいろベストプラクティスが検討されているみたいです。
Gitを使ってバージョン管理することで後から不要になったコードをコメントアウトして残す必要もなくなり、メンテナンスがやりやすくなります。またReactやAngular2などビルド作業が必要になる開発では、静的リソース以外にコードを管理できる環境が必須になると思うのですが、Gitリポジトリを用意することでビルド時の設定ファイルなどを管理できるようにもなると思います。
以上、BitbucketをつかったSalesforceのプロジェクト管理についてでした。
