Macでbuild.gradleのversionCodeやversionNameを更新しようとすると、どのファイルをどう直せば安全か迷いますよね。
この記事を読むと、手元のMacで安全にバージョン番号を上げるための実践的な手順や、よくある失敗の回避法、CIでの自動化までわかります。
| 項目 | 内容 |
|---|---|
| ステップ付き実例 | 手で行う具体的コマンドとファイル編集例を段階的に紹介します。 |
| 安全な運用のコツ | バックアップとgit運用のコツで事故を防ぐ方法を説明します。 |
| 自動化と両DSL対応 | GroovyとKotlinDSL両対応のサンプルスクリプトとCI連携例を用意します。 |
少しの操作でリリース作業がぐっと楽になりますから、落ち着いて手を動かしていきましょう。
Android博士初めてでも心配いりません。落ち着いて手順どおり進めれば必ず成功しますし、困ったら手順に戻ってやり直してください。
MacでAndroidのbuild.gradleのversionCodeとversionNameを手動で更新する方法
MacでAndroidのversionCodeとversionNameを手動で更新する方法について、優しく手順をまとめてお届けします。ここではGUIで直接編集する方法とターミナルで置き換える方法の両方を扱いますので、好きな方法を選んでください。
どちらのやり方でも必ず編集前にファイルのバックアップかgitのコミットを作ってから進めてください。小さなミスでビルドが通らなくなることがあるので、失敗しても戻せるようにしておくと安心です。
Android博士怖がらずに一歩ずつ行きましょう。複雑に見えても手順どおりにやれば大丈夫です。困ったら落ち着いてログとファイルの差分を見てください。
AndroidStudioでアプリモジュールのbuild.gradleを直接編集するパターン
AndroidStudioでアプリモジュールのbuild.gradleを直接編集する方法は直感的で、GUIが好きな人に向いています。プロジェクトビューから該当モジュールを開き、appモジュール内のbuild.gradleまたはbuild.gradle.ktsを探して編集します。
編集後はGradleSyncしてエラーがないか確認し、エミュレータや実機でビルドして動作確認してください。KotlinDSLを使っている場合は記法が少し違うので行末やクオートに注意してください。
app/build.gradleAndroidStudioで該当モジュールのbuild.gradleを開く場所と方法
AndroidStudioの左上にあるProjectビューでAndroidではなくProject表示に切り替えるとファイル構成が見やすくなります。appフォルダを展開して該当のbuild.gradleファイルを探してください。
該当ファイルをダブルクリックしてエディタで開きます。Gradleスクリプトが複数ある場合はモジュール側のファイルを編集してください。
defaultConfigのversionCodeとversionNameを編集してGradleSyncしてビルド確認する手順
build.gradleのdefaultConfigブロック内にあるversionCodeとversionNameを書き換えます。数値や文字列の書式を崩さないように注意してください。
画面上部のSyncボタンかFile→Sync Projectを実行して依存関係や設定の反映を確認します。エラーが出たら行単位で戻せるようにしておくと安心です。
Runでエミュレータや端末にインストールして挙動を確認します。ログやインストールの成否を見て問題がなければコミットしてください。
Macのターミナルでsedやawkを使ってファイルを置き換えるパターン
Macのターミナルでsedやawkを使ってファイルを置き換える方法は自動化やスクリプト化に向いています。複数モジュールやCIでの運用を考えている場合は、手動編集よりこちらの方がミスが少なく済むことが多いです。
実行前に必ずgitで差分が取れる状態にしておき、まずはdry runで置換結果を確認してください。macOSのsedはinplace編集のオプションが少し特殊なので注意が必要です。
ターミナルでプロジェクトルートに移動する（cd ~/path/to/project）
ターミナルでプロジェクトのルートフォルダに移動します。例cd~/path/to/projectと入力してエンターしてください。ここからコマンドを実行します。
sedやawkでversionCodeをインクリメントしversionNameを置換して保存するコマンド例と使い方
| 項目 | 内容 |
|---|---|
| バックアップを作る | cp app/build.gradle app/build.gradle.bak |
| versionCodeをインクリメントする例 | NEW=$(( $(grep -m1 -o ‘[0-9]\+’ app/build.gradle) +1 ));sed -i ” -E “s/versionCode[[:space:]]+[0-9]+/versionCode $NEW/” app/build.gradle |
| versionNameを置換する例 | sed -i ” -E ‘s/versionName “[^”]+”/versionName “1.2.3”/’ app/build.gradle |
./gradlew assembleでビルドしてエミュレータや端末で動作確認する手順
プロジェクトルートで./gradlew assembleを実行してビルド成果物を作ります。問題がなければAPKやAABが作成されます。
デバッグAPKならadb install -r app/build/outputs/apk/debug/app-debug.apkで端末にインストールして動作確認します。
アプリを起動して主要な画面を確認し、問題があればadb logcatやAndroidStudioのログを見て原因を特定してください。
MacでGradleタスクやシェルスクリプトを使ってビルド番号を自動更新する方法
ビルド番号を毎回手で上げるのは時間の無駄でミスの元になります。MacでGradleタスクやシェルスクリプトを使うと、versionCodeとversionNameを安全に自動更新できます。
ここでは実際に動く最小限のやり方を、Gradleタスクパターンとシェルスクリプトパターンでそれぞれ示します。ローカルで試してからCIに組み込む手順や注意点もわかりやすく説明します。
まずはローカルで安全に動作確認をすることが大切です。困ったときの巻き戻し方法やgit運用のちょっとした工夫も合わせて紹介します。
app/build.gradleにカスタムGradleタスクを追加して自動化するパターン
app/build.gradleにカスタムGradleタスクを追加するパターンはGradleのDSLで完結するため扱いやすいです。Gradleタスク側でversionCodeを計算してファイルに書き戻すことでAndroidビルドがその値を使います。
メリットはGradle実行内で完結する点とCIでそのまま動く点です。デメリットはGroovyやKotlinスクリプトを触る必要があることですが、最小限のサンプルを真似すれば安心です。
app/build.gradleのどの位置にタスクを追加するかと最小限のタスク例
androidブロックの外、ファイル末尾付近に置くと見つけやすく他タスクと干渉しづらくなります。
タスク名はbumpVersionなどにしてversionCodeを読み取り増加させファイルに上書きするだけの短い処理にします。
./gradlew bumpVersionなどでタスクを実行してビルドに反映する流れ
./gradlewbumpVersionを実行してbuild.gradleを更新します。
続けて./gradlewassembleDebugなどでAPKを作ると更新済みのversionCodeが反映されます。
Macのシェルスクリプトで読み取り→インクリメント→書き戻すワークフローを使うパターン
Macのシェルスクリプトパターンはシンプルで幅広い環境で動きます。build.gradleをテキストとして読み取り正規表現でversionCodeを抜き出し数値をインクリメントして書き戻す流れが基本です。
この方法はGradle側を触らずに済むので導入が速いです。CIではコミットやタグ打ちと組み合わせることで確実に一意のビルド番号を作れます。
シェルスクリプトでbuild.gradleから値を抽出してインクリメントする具体的な書き方
- 1.sedやgrepでversionCodeの行を抽出する。抜き取った数値をexprやbashの算術でインクリメントする。
- 2.置換はsed-iやperlで行いファイルを上書きする。差分が出る場合はgitでコミットする運用にする。
- 3.動作確認はローカルで行いCIではスクリプト実行後にビルドを走らせる流れを作る。
スクリプトに実行権限を付けてローカルやCIで実行するタイミングの決め方
- 実行権限付与はchmod+xスクリプトファイルで行う。ローカル実行前に必ず動作確認する。
- ローカルはビルド前に手動で実行するのが安全。CIはマージ後やリリースタグ作成時に自動で走らせるのが一般的。
- CI実行時は並列実行やキャッシュに注意して一意性を担保するためコミットやタグ保存を組み合わせる。
MacでGitタグやコミット数を使ってビルド番号を自動生成する応用手順
MacでGitの情報を使ってAndroidのビルド番号を自動化すると手間が減りミスも減ります。ここではコミット数をversionCodeに使う方法とタグをversionNameに同期する方法を実践的な手順と運用のコツで優しく紹介します。
実際にはローカルでの小さなスクリプトからCI連携まで幅があります。まず全体像を把握してから自分のワークフローに合う手法を選ぶと失敗が少なくなります。
- コミット数をそのままversionCodeにする単純パターン。ローカルでもCIでも扱いやすいメリットがあります。
- 最新タグとコミット差分を組み合わせてversionNameを作るパターン。ユーザー向けの見た目がきれいになります。
- リリースタグをversionNameに同期してCIでbuild.gradleを書き換える運用。配布フローが安定します。
Gitのコミット数やタグからversionCodeとversionNameを作るパターン
versionCodeは必ず増えていく整数である必要があります。単純にコミット数を使う方法は導入が速いですが桁が足りなくなったりブランチ運用で衝突する懸念があるためベース値に乗算する工夫が有効です。
versionNameはユーザー向けの文字列なのでタグをそのまま流用するのが分かりやすいです。タグが無い場合はプレフィックスとコミット数を組み合わせると人間にも読みやすくなります。
git rev-listやgit describeで数やタグを取得してbuild.gradleに反映する簡単なスクリプト例
ローカルリポジトリからコミット数を取得してversionCodeの基礎値にします。コミット数そのままでは桁や衝突を考慮してベースを掛けると安全です。
最新のタグやタグとHEADの差分を取得してversionNameに反映します。タグが無い場合はプレフィックスとコミット数で代用できます。
スクリプトでbuild.gradleのversionCodeとversionNameを書き換えて通常通りビルドします。自動化すると手作業ミスが減り再現性が上がります。
リリース時にタグをversionNameに同期してビルド・配布する運用フローの作り方
- リリースブランチを確定して注釈付きタグを作成する。注釈付きタグは履歴が分かりやすくて便利です。
- タグをリモートにpushしてCIでタグ検出を行う。CIはタグをversionNameとして取り込むよう設定します。
- CIでversionCodeをコミット数やビルド番号から算出してビルドを実行する。アーティファクトはタグ付きで保存します。
- 署名やバージョン確認を行った後に配布する。ストアへの登録前に必ずチェックを入れてください。
よくある質問
- versionCodeとversionNameはどちらを更新すればよいですか。
versionCodeはアプリの内部番号となる整数です。GooglePlayでは以前のversionCodeより大きくないとアップロードできません。versionNameはユーザー向け表示なので、両方を意識して更新すると分かりやすいです。
- Macのターミナルだけで安全に更新できますか。
できます。build.gradleやgradle.propertiesをテキストエディタで編集した後にgitでコミットしてテストビルドを作れば安心です。慣れてきたら簡単なスクリプトで自動化するとミスが減ります。
- 自動でversionCodeを増やす簡単な方法はありますか。
あります。CIでビルドごとにインクリメントするスクリプトやgradleタスクを用意すると手作業が不要になります。コミット数や日付を元に番号を作る運用も現場ではよく使われます。
- マルチモジュールプロジェクトではどう管理すればよいですか。
共通のgradle.propertiesでversionCodeを一元管理して各モジュールから参照するとずれにくくなります。手動で個別に変えるより整合性が保ちやすくなります。
- 誤ってversionCodeを下げてしまったらどうすればよいです。
versionCodeを下げるとGooglePlayにアップロードできません。元のバージョンより大きい値に上げ直す必要があります。履歴確認や復旧のためにgitタグを残しておくと助かります。
まとめ
お疲れさまです。MacでAndroidのbuild.gradleのversionCodeとversionNameを安全に更新する方法をやさしくまとめました。手作業での確実な手順と日常的に使える自動化のコツをつまずきやすいポイントと合わせて紹介しています。
特に注意したいのはversionCodeが上書きできない増分管理である点とversionNameは表示用である点です。小さなシェルスクリプトやgitタグで番号を自動生成すると、うっかりミスがぐっと減ります。CIに組み込む場合はローカルで手順を確認してから移すと安心です。
最後に必ずローカルで署名済みのapkやaabを動作確認すると安心感が生まれます。複数ブランチで作業する場合はバージョンルールを短く決めると混乱が減ります。ここまで押さえればリリース前の手戻りはかなり少なくできます。
Android博士困ったときは落ち着いて一つずつ確認してください。小さなチェックを習慣にすると公開作業がずっと楽になります。
versionCodeは必ず整数で前回より大きくする必要があり、同じ番号ではストアに上げられない点に注意してください。