こんにちは！ソリューションコンサルタントの田上です。
近年のWebアプリケーション開発においては、効率と柔軟性を両立させることが求められています。特に、開発プロセスにおいてデザインとコードの仕様変更が頻繁に発生する場合、それらをシームレスに管理できることはプロジェクトの成功に不可欠です。
そんな中で注目されているのが App Builder です。このツールは、ビジュアルデザインから自動的にコードを生成する画期的な機能を備え、デザインと開発の一体化を強力にサポートします。
しかし、一部の開発現場からは「App Builder は一次開発のみに適しているのでは？」という懸念が挙がっていることも事実です。具体的には、一度自動生成されたコードにカスタマイズを施した後、App Builder へ再インポートできない仕様が課題とされています。
このため、「デザインの仕様変更」や「二次開発で新たなデザインを反映したい」場合に、App Builderが使えなくなるのではないかというご心配の声をお聞きします。
この記事では、GitHub を活用したブランチ構成（main-dev-feature）を導入することで、こうした課題をクリアでき、App Builder をプロジェクトの全てのフェーズで適用してデザインを反映できる解決策を紹介します。これにより、App Builder の利用者は何度でもデザインの仕様変更に対応することができ、二次開発の新たなデザインを取り込むことができるようになります。
App Builder を使用してWebアプリケーションを開発する際には、デザインの変更とカスタマイズしたコードを効果的に管理するためのマージ戦略がとても重要です。それでは早速見て行きましょう。
- App Builder へ「再インポートができない」という問題の解決策
- ３つのブランチ構成と目的を理解する
- シナリオの例
- 継続的なデザイン変更を可能にする App Builder の活用法
- まとめ
- App Builder の利点を活かしたマージ戦略を始めましょう！
App Builder へ「再インポートができない」という問題の解決策
App Builder はWebアプリケーションの統合開発環境として、７つのコードを自動生成することができるローコードツールです。ドラッグ＆ドロップでデザインを作成して、ワンクリックでコード自動生成（プロジェクトファイル一式を出力）することができます。
しかし、一方で App Builder からコード自動生成した後に、「独自カスタマイズ（コーディング）」を施したときに、再び「App Builder へインポート」してデザインに対して独自カスタマイズのコードを反映させることは出来ません。（再インポートできない仕様）
また、開発現場からは効率と柔軟性が求められる背景から、「デザインに対する仕様変更」と「独自カスタマイズ（コーディング）」をそれぞれが影響せずに独立してバージョン管理したい、という声をよくお聞きします。開発フェーズの上流工程だけでなく、全てのフェーズにおいて App Builder を活用したいというニーズが多く寄せられています。
今回の記事では、デザインとコードを３つのブランチで管理しつつ、統合してマージする具体的な手順をご紹介します。GitHub の機能を活用することで、App Builder を用いた継続的な開発（イテレーション）が実現可能です。
３つのブランチ構成と目的を理解する
まず、概要理解としてブランチ構成を理解しておきましょう。本記事では、以下の３つのブランチを使用します。
Ａ．デザインブランチ（main）
デザインブランチ： App Builder で作成したデザインコードは、ワンクリックで GitHub にプッシュすることが可能で、選択したリポジトリの main ブランチとして保存されます。この main ブランチが App Builder で自動生成されたデザインコードを保存するためのブランチです。このブランチは、デザインの変更が発生するたびにコミットが追加されます。
Ｂ．統合ブランチ（dev）
統合ブランチ： dev ブランチは、プロジェクト全体を統合する役割を果たします。main ブランチで行われたデザインの変更と、後述するコードブランチ（feature ブランチ）で追加された独自のカスタマイズコードをマージするためのブランチで、最終的な統合を行います。
この dev ブランチは、フロントエンドとバックエンドの開発を統合するハブのような役割を持ち、プロジェクトが進行してもデザインと機能を一元管理できる仕組みを提供します。
Ｃ．コードブランチ（feature）
コードブランチ： feature ブランチは、バックエンドやビジネスロジックの独自カスタマイズを行うためのブランチです。例えば、DB処理やAPI処理など、プロジェクトの核心部分を担う開発が行われます。feature ブランチで行われた変更は、dev ブランチへ統合され、最終的にプロジェクト全体のコードに反映されます。
この構成を採用することで、デザインとコードが分離管理され、必要なときに App Builder を活用してデザインの修正や追加を行うことが可能になります。例えば、デザインの仕様が変更された場合でも、App Builder を使って新しいデザインを作成し、それを main ブランチに反映させ、統合ブランチでマージしてプロジェクト全体に適用することができます。
シナリオの例
実際のシナリオの例を見てみましょう。このシナリオでは、UI デザイン担当者と開発者が協力してアプリケーションを開発します。
まずは UI デザイン担当者が App Builder を使ってアプリケーションの UI を作成し、できあがった UI プロジェクトを GitHub リポジトリの main ブランチにプッシュします。このシナリオでは、ここからアプリケーションの開発が始まります。
次に、開発者は main ブランチから dev ブランチを作成し、プロジェクト全体の統合に備えます。
開発者は続けて、アプリケーションのロジックの追加に取りかかります。例えば UI デザイン担当者が作成したページ上のボタンについて、これがクリックされたときのデータ取得と表示の処理を実装する、といった作業を行ないます。開発者によって追加・変更されたコードは、feature ブランチにコミットし、最終的に dev ブランチにマージします。
さてここで、UI デザインに変更の必要が発生したとします。例えば新しいページが追加になるであるとか、既存のページのレイアウトが調整される、あるいはフォーム画面に追加のフィールドが必要になる、などです。どうしたらいいでしょうか？
何の問題もありません!
UI デザイン担当者は、App Builder を使って普通にデザイン変更の作業を継続し、再び GitHub にプッシュするだけです。すると GitHub 上にこのデザインの変更についてのプルリクエストが作成されますので、このプルリクエストを承諾することで、変更後のデザインが main ブランチにコミットされます。
次の作業として、開発者は main ブランチでのデザイン変更のコミットを dev ブランチにマージします。多くの場合、このマージ処理は何の問題もなく完了するでしょう。あるいは、開発者が行なった変更と、UI デザイン担当者が行なった変更とが衝突することがあるかもしれませんが、その場合もさほど労せず解決できるでしょう。
この main ブランチから dev ブランチへのマージ作業によって、デザインの変更がアプリケーションの開発に反映されることになります。
あとは再び、開発者が最新の dev ブランチを開始地点として、UI デザイン担当者が行なったデザイン変更に対し、アプリケーションのロジックの追加・変更を行ない、成果を feature ブランチにコミットし、最終的に dev ブランチにマージする、といった作業を繰り返していくことになります。
このように、UI デザイン担当者と開発者が協力して GitHub を介してアプリケーション開発を進めることで、開発の途中で都度デザインの追加・変更を App Builder で行ないながら、アプリケーションの開発を継続できることわかります。
このシナリオでは UI デザイン担当者と開発者の 2 名による例を示しましたが、もちろん、より多くのメンバーが関わるプロジェクトにおいても同様の方法で進めることができます。あるいは UI デザイン担当者と開発者が同じ人物である場合も、このシナリオで紹介した手法を採用することで、デザインに App Builder を使用し開発生産性を高めることができます。
継続的なデザイン変更を可能にする App Builder の活用法
この GitHub のブランチ構成は、デザインが作成された後も App Builder を何度でも使用できるという強力な利点をもたらします。デザインの仕様変更や新たなUI要素の追加が必要になった際、App Builder は一次開発に限定されたツールではなく、全ての開発フェーズにおいてプロジェクトの進行に合わせたツールとして機能します。
さらに、App Builder は既存の開発プロセスにもスムーズに組み込むことができるため、企業の開発チームは従来のワークフローを大きく変えることなく、柔軟かつ効率的にデザインとコードの管理を行いながらプロジェクトを進めることが可能になります。「デザインの仕様変更」や「二次開発の新たなデザイン」といった課題に対しても、GitHub を中心に App Builder を統合することで、既存のプロセスを維持しつつ、スムーズな開発を継続することができます。
まとめ
App Builder は、一次開発にとどまらず、GitHub との連携によりプロジェクトの全フェーズで使用可能な強力なツールとして活用できます。特に、デザイン変更が発生する可能性の高いプロジェクトにおいて、GitHub のブランチ構成を適切に導入することで、デザイン変更とカスタマイズコードの統合がシームレスに行える環境を構築できます。
さらに、App Builder は既存の開発プロセスにもスムーズに組み込むことができ、これまでのワークフローを大きく変更する必要がありません。これにより、企業は開発効率の最大化と柔軟なデザイン変更対応を両立しながら、競争力のあるアプリケーションを迅速に市場へ投入できるでしょう。
今後の開発プロセスにおいて、App Builder と GitHub を活用することで、プロジェクトのあらゆるフェーズで優れたデザインとコードの管理方法を実現しましょう。
App Builder の関連記事はコチラ
App Builder の利点を活かしたマージ戦略を始めましょう！
このブログ記事では、App Builder と GitHub を用いたデザインとコードのブランチ管理、及びマージ戦略について詳しく解説しました。
Infragistics App Builder はWebアプリケーションの開発プロセスを、効率的にサポートする強力なツールです。デザインとコードを GitHub でブランチ管理して、仕様変更に強いマージ戦略を導入することで、プロジェクトのスムーズな進行と高い品質を確保できます。App Builder の利点を活かしてコードを統合管理することで、社内のソフトウェア開発のプロセスを大幅に改善できます。
ぜひ、App Builder を活用してデザインからコード自動生成する世界を体験してみてください。すべてを体験するには、App Builder 無料トライアル にアクセスして最新バージョンを入手してください。
- 「こんなことは実現できるの？」
- 「どうやって実装すれば良いの？」
といった開発上の疑問にソリューションコンサルタントが直接お答えします。
ぜひ japansalesgroup@infragistics.com まで、お気軽にお問合せください。ご意見ご要望を心よりお待ちしています。
