Alteryx Serverの移行先バージョンを考える

[gawa]

はじめに

Alteryx Serverの管理者にとって、定期的なバージョンアップは避けて通れない重要な業務です。しかしながら、「次はどのバージョンにアップグレードするか？」という判断は、簡単ではありません。この記事では、その意思決定を支援するためのヒントや考え方をご紹介します。

バージョン表記

まず、Alteryx Serverのバージョン表記について簡単に整理しておきます。

Alteryx Serverのバージョンは「20XX.Y.ZZZ」という形式で表されます。このうち：

• 20XX.Y がメジャーリリースバージョン
  （20XXはリリース年、Yはその年の何回目のリリースか）

• ZZZ がマイナーパッチバージョン
  （パッチやバグ修正などが加えられた回数）

たとえば「2024.2.1.94」というバージョンは、「2024年の2回目のメジャーリリースに対する、3回目のパッチ修正」と解釈できます。

なぜバージョンアップが必要か？

多くのユーザー企業にとって、最も避けたいのは「バージョンアップ後に、これまで正常に動いていたワークフローがエラーになる」ことではないでしょうか。

新機能の追加は魅力的ですが、何よりもまず、従来通りの安定動作を確保することが前提になります。また、Alteryx Serverの製品サポート期間はメジャーバージョンの初回リリースから2年間と定められており、長期間同じバージョンを使い続ける運用はリスクを伴います。

もちろん「サポートが切れても今のバージョンを使い続けたい」という方針を否定するものではありません。ただしその場合でも、バージョンアップの負担を将来に繰り越しているという認識は持っておくべきでしょう。

💡 一般に、現在のバージョンと移行先のバージョンの差が大きいほど、バージョンアップ作業は複雑かつ困難になります。

「最新版にすべき」とは限らない

海外のコミュニティ記事では、「最新のメジャーバージョンではなく、1つ前のバージョンを選ぶこと」を推奨しています。これは、最新リリース直後には予期せぬ不具合が含まれている可能性があるためです。

（※補足：これはAlteryxに限った話ではなく、ソフトウェア全般に共通する事情です。魅力的な新機能を迅速に提供しようとするからこそ、一定の不具合は避けがたく、その後のパッチで徐々に安定性が増していきます。Alteryxが“不具合だらけ”の製品を出しているというわけではない点はご理解ください。）

結局のところ、移行先バージョンの選定は、

• 2年間のサポート期間

• 製品の安定性（既知の不具合の許容度）

この2つのバランスをどう取るか、という意思決定といえます。そのためには、リリースノートを確認することが重要です。

リリースノートを定量的に分析する

リリースノートには、各バージョンにおける「既知の不具合（Known Issues）」と「修正済みの不具合（Fixed Issues）」が掲載されています。これをもとに、ユーザー企業ごとに「自社にとって許容可能なバグ／そうでないバグ」を見極めることが基本です。

さらに、以下のような定量的分析も意思決定に役立ちます。

下図は、Alteryx Designerを用いてリリースノートWebサイトをWebスクレイピングし、作成したバーンダウンチャートです。各メジャーバージョンごとにグループ化し、マイナーバージョンごとの「既知の不具合の数」と「修正済みの不具合の数」を視覚的に表現しています。

このようなチャートを見ることで、

• 既知の不具合が順調に減っているか？

• 修正済みの不具合が頭打ちになっているか？

といった製品の安定性の傾向を、定性的ではなく定量的に把握できます。

また、こうした視覚的な資料は、非エンジニア層にも分かりやすいため、社内での合意形成にも有効です。

おわりに

Alteryx Serverの移行先バージョンに共通の正解はありませんが、この記事で紹介したような考え方は一つの指標になるかと思われます。また、他のユーザ企業と交流するなどして口コミで情報収集することも、とても重要です。

注意事項

• この記事に添付しているWFは十分動作確認しておりますが、結果の正しさについては保証いたしかねます
• 添付WFを二次利用される場合はコミュニティのガイドラインに従ってご利用ください

AlteryxServer_ReleaseNote_HTML_Parse.yxmd

[Yoshiro_Fujimori]

@gawa ,

昨日のユーザーグループ会（サーバー分科会）では発表いただきありがとうございました。

移行先バージョンの選定に関する話の中で、このページをご紹介いただいたので ワークフローをダウンロードして拝見しました。

（社内環境では Download Tool がエラーになるため実行はしておりませんが）

Filter (63) のところで

　!StartsWith([ID], "GCSE")

と Issue ID を "GCSE" で始まるものに絞られていますが、この目的は何でしょうか。

ページを見ると

　GCSE, TGAL, TPRI, TCPE, GBETA, ...

といったパターンがあり、分類用のコード体系があると推測しますが...

[gawa]

@Yoshiro_Fujimori 記事読んでいただけて嬉しいです。

この条件式は、頭に ! をつけているので、"GCSE"以外のIssue IDを抽出しております。

　!StartsWith([ID], "GCSE")

以下、Alteryxの方に伺った話の伝聞です：

Issue IDの先頭の英字4桁は、GCSE/TCPE/TGAL....のように複数の種類がありますが、GCSEは無視して構わないようです。

GCSEはサポート・ケースから発生したIssueを管理する区分とのことで、最終的にはGCSE以外(TCPE/TGAL....)の区分にマージされるそうです。TCPE/TGAL....の使い分けは分かりませんでしたが、おそらくIssueの内容(UI関連、バックエンド系)で区分してるようにみえます。

リリースノートをご覧いただくと、GCSE　と　TCPE/TGAL....が併記されているものがありますが、上記解釈でいくと、それらのIssueは元々サポート・ケース由来のIssueだと判断できます（GCSEが無い場合は、製品開発チームで自主的に発見したIssueということなのでしょうね）

[Yoshiro_Fujimori]

なるほど、よくわかりました！

詳細なご説明ありがとうございました。