ABANCA Corporación Bancaria, S.A.

スペイン北部ガリシアに本拠を置くスペインの銀行。Abancaはスペインに約700の支店を持ち、自動車、観光、テキスタイル、テクノロジーなどの多くの産業に投資しています。

プライベートパッケージとProGetによって改善されたAbancaのソフトウェアデプロイ。

The Challenge:

Abancaは、EU内に本拠を置く銀行として、すべてのスペインの銀行や他のEU加盟国の銀行と同様、EUが定めた規則、規制、政策の対象となります。 2007年、EUは支払いサービス(PSD)の規制を新たに制定しました。 EUのウェブサイトとプレスリリースによると、この規制は、EU全体の単一市場の決済のための法的基盤を提供されており、 PSDは、EUのすべての決済サービスに適用されるモダンで包括的なルールを確立することを目指しています。 その目標は、国境を越えた支払いを加盟国内の国内での支払いと同じくらい簡単かつ効率的かつ安全なものにすることです。 PSDはまた、新規参入者への決済市場を開放することで競争力を向上させ、効率の向上とコスト削減を促進しています。 同時に、この規制は単一でユーロの決済をおこなっているエリアに必要な法的プラットフォームを提供します。

2016年8月のPSDの改定によりAbancaは2017年半ばまでに、ソフトウェアのAPIを作成する必要がありました。これにより、Abanca内部 で”Morphe”プロジェクトの形でProGetの使用が順々に開始されました。 つまり銀行のデジタル化です。

Abancaには、.NetとJavaの両方で複数のプラットフォーム(オンライン、モバイル、その後まもなく廃止される予定だったブラックベリーも含めて)において商業的および個人的な銀行業務を行うプラットフォームを開発している多くの開発者がいるという事実に照らして、Abancaアーキテクチャチームは、 コードをパッケージ化して展開するための最新のパッケージベースの方法論を採用しました。 この方法論の明らかな利点の1つは、開発者が広大なサードパーティ製パッケージのコミュニティにアクセスできるようにすることで、開発が加速されることです。 ソリッドリリースプロセスと組み合わせることで、このパッケージベースの方法は、より良いソフトウェアを、より速く、より確実にリリースすることが可能になりました。

パッケージベースの方法論は採用されていません。 セキュリティ上の理由により、銀行はフィードがダウンするリスクやパッケージが削除される可能性があるサードパーティ製のパブリックパッケージを使用できないため、内部化する必要があります (外部の障害が発生した場合にローカルにキャッシュ保存する)。同時に異なるサーバー上のさまざまなタイプのパッケージ全てのフィードをホスティングする問題に対処します。

これらの課題を意識しながらパッケージを使用することに着実に取り組んでいるAbancaのアーキテクトチームは、ユーザーのパッケージフィードを民営化するユニバーサルパッケージマネージャーを見つけることにした。 主に.Netのショップとして、ProGetは最適な選択肢でした。

“Morphe”プロジェクトは短期間で、Abanca社にこの近代的なパッケージベースの方法論を通して、一貫性とセキュリティを備えた35のアプリケーションとプロジェクトのデリバリーを自動化することができました。

Solution:

ProGetの統合に先立ち、Abancaは、開発者がアプリケーションをサーバーにデプロイすることを許可しないポリシーを策定しました。開発者はコンパイルとテストをローカルで行い、リリースはコンパイルサーバーを通じてプロダクションにプッシュするワークフローへと変更になりました。 このプロセスは、AbancaのJavaプラットフォームとそのコアバンキングシステムが動作するメインフレームを通じて実現しました。

これはAPIの作成と同様にEUの規制では要求されていませんが、Abancaはこれをベストプラクティスとみなし、.Netプラットフォームで行う方法がないことに頭を悩ませていましたが、ProGetを統合することで問題は即座に解決されました。Abancaはコンパイルサーバーを使用して、非常に簡単に管理されたアプリケーションをデプロイ可能になりました。

あらゆるアプリケーションで動作する全ての開発者のデプロイ・プロセスは、下記の通りです。開発者はコンパイルサーバ(コンパイルツールとビルドツールをインストールしたWindowsマシン)にソースコード(パッケージではなくソースコード)をアップロードし、サーバーアプリケーションはmsbuild(.Netプロジェクト用)またはMavenによってコンパイルサーバ上で再構築されます (Javaプロジェクトの場合)。 コンパイルサーバーでは、開発者が使用するものと同じパッケージの異なる反復が、ビルドプロセスによってダウンロードされます(ビルドツールのインストールポイントとProGetのパッケージ/アーティファクトが抽出されてから、それらのパッケージがアプリケーションサーバーにデプロイされます) 一般的なxcopyデプロイメント方法を使用してアプリケーションサーバーにデプロイされます。

Abancaのアーキテクト管理者でありProGetのパワーユーザー、Julio Angel Fernandez Vilas氏によれば下記のような利点が挙げられています。

  • 3つの異なる環境におけるアプリケーションの展開およびプロモーションの品質
  • 銀行で使用されるライブラリの統一と単純化(開発者とサーバは同じライブラリのセットを使用する)
  • 生産ソースのベースラインを維持することが容易

開発者がAbancaの新しいプロセスにデプロイする前に、リコンパイルサーバーでコーディングする際に使用したものと同じパッケージが繰り返しダウンロードされていることに気付いた場合、ProGetを統合した後でAbancaがProGetを使用して見つけた追加の利点にも気が付くことでしょう。 およそ1週間で、Abancaのアーキテクトチームは開発者の公開パッケージフィードへのアクセスを遮断しました。 この場合、開発者が(新しい)パッケージにアクセスする必要がある場合は、アーキテクトチームにそのパッケージを依頼する必要があります。

EUで要求されたものではありませんが、管理されたプロセスを作成するためのベストプラクティスと、社内外の全てのAbancaユーザーの統一されたエクスペリエンスがあります。 この理論の根底にあるものは、開発者が公開フィードにアクセスできる場合、時間の経過とともに、さまざまなUIを持つ異なるライブラリを使用し始めて、アプリケーションに一貫性のないエクスペリエンスをもたらすという予測でした。 実際に何が起こるかを知る方法はありませんでしたが、1年後にこのプロセスは非常に滑らかで、一貫性のある統一されたエクスペリエンスをもたらしました。 ProGetはこの措置の「民営化」を可能にするだけでなく、Bower、NuGet、NPM、Mavenなど、民営化されたユニバーサルパッケージマネージャー内で複数のフィードタイプを使用する権限をAbancaに付与しました。

Results:

“Morphe”プロジェクトは、Abancaにこの近代的なパッケージベースの方法論を通して、一貫性とセキュリティを備えた35のアプリケーションとプロジェクトのデリバリーを自動化することに短期間で成功しました。

また、内部デプロイ、JSONエディタ、およびVisual Studioに統合された内部開発環境を拡張するためにProGetと統合する独自の拡張機能も作成できました。 これらの拡張により、”Morphe”プロジェクトの次なる目標に向かって、ProGetはAbancaがデプロイを予定している多くのプロジェクトとアプリケーションへと、一貫性とセキュリティを提供し続けます。