Git系ホスティングサービスが広まる前に見られたソース管理手法

Git系ホスティングサービスやCI/CDツールが広まった現在のシステム開発の現場では、以下のようなソース管理が一般的です。

しかし、それが広まる前の昔のシステム開発の現場では、以下のようなソース管理が見られました。

この記事では、昔のソース管理の問題点を挙げていきます。


昔のソース管理によって発生する具体的な問題は、主に以下の二つです。
①商用環境に配置される実行ファイルがどのように作られたのか不明
②最新のソースコードが適切に管理されない可能性がある

以下では、それぞれの問題点について説明します。

①商用環境に配置される実行ファイルがどのように作られたのか不明

現在のソース管理では、Git系ホスティングサービスの中でビルドが行われます。
このビルドの作業は、Git系ホスティングサービスの管理者が実施する、もしくはCI/CDツールの設定に基づき実行されるため、開発者任せになることがなく、どのソースファイルがビルドされたのかも明確です。
しかし、昔のソース管理では、開発者がテストのために開発環境でビルドした実行ファイルがそのまま商用環境に持ち込まれることがしばしばありました。
そのため、ビルド作業が開発者任せになりますし、どのソースファイルがビルドされたのかも不明になります。
(開発者の環境を見に行って推測したり、開発者の申告を信じたりするしかありません)
昔のソース管理では、この問題により、意図しないソースファイルがビルド時に含まれてしまうことによるデグレードが起こりやすくなります。

②最新のソースコードが適切に管理されない可能性がある

現在のソース管理では、商用環境向けにビルドを行ったソースファイルをそのまま世代管理します。
そのため、商用環境向けのビルドに使用したソースファイルの紛失は起こりにくいです。
しかし、昔のソース管理では、リポジトリへのソースファイル格納と商用環境への実行ファイル配置が別作業になることがしばしばありました。
このような運用を行った場合、リポジトリへのソースファイル格納を忘れても本番運用には影響がない、という状態が起こり得ます。
このことにより、ソースファイルの世代管理の作業が漏れやすくなり、ソースファイル紛失の原因になります。
例えば、リポジトリへのソースファイル格納を忘れ、かつ開発環境のリプレースが発生した場合、リプレース前の開発環境にのみ存在していたソースファイルは失われてしまいます。


前回の記事に引き続き、過去の作業手順について触れた記事を書きました。

今回の記事で紹介した昔のソース管理とその問題点は、何れも私が実際に経験したものです。
現在では信じられない話かもしれませんが、私が経験した現場では、デグレードやソースファイル紛失が問題となることがあり、それを防ぐために重厚長大なルールが制定され、開発効率が落ちていました。

現在は、Git系ホスティングサービスやCI/CDツールにより、少ない労力でこういった問題の発生を未然に防げる運用を行えるようになりました。
良い時代になったと思います。

CDツールを使わない場合のデプロイ手順のイメージ

現在の開発現場・運用現場では、CD(Continuous Delivery)ツールを使用したデプロイ(サーバーへの資材配置)が一般的になっています。
CDツールの設定を行うのは一部の技術者のみであることもあり、CDツールを使用しない場合の原始的な手順でのデプロイ手順は、経験の浅い技術者にはイメージしにくいものであると感じています。

そこで、この記事では、CDツールを使用しない場合のデプロイ手順のイメージを書いていきます。
デプロイ手順を知ることで、CDツールを使う理由やそのありがたさを理解しやすくなると思います。


開発した機能を本番サービスに反映させるためには、開発環境で開発を行った資材(プログラムの実行モジュールやスクリプト、設定ファイル等)を商用環境に配置する必要があります。
配置を行うためには、最低限下記の作業が必要になります。
(コマンドのイメージも併記します)

1.商用環境のサーバーへのログイン

2.ファイル共有サーバーからの資材取得

3.資材(圧縮ファイル)の解凍

4.解凍後の資材の配置

上記の作業を行うだけでも、コマンドの誤り・漏れによる作業ミスの可能性がありますし、入るサーバーを間違えてしまうことすらあります。
作業を引き継ぐことにも困難さを伴い、作業手順書のようなものが必要になります。

加えて、下記のような作業を伴うことも多く、実際の手順はより複雑になります。

  • デプロイ時のサービス停止や機能制限、それに伴う設定変更(サーバー毎に設定が異なることも多い)
  • デプロイ前のバックアップ取得
  • デプロイ後の定型的な確認作業

作業ミスを防いだり引継ぎを容易にしたりする上で、CDツールの利用が有効になります。
CDツールでは、コマンドや設定を登録し、複数のサーバーに対して画面からGUIベースで作業することができるようになります。

イメージとしては以下のようなものになります。
(以下は、CircleCIのチュートリアルの一部です)

Hello World – CircleCI


今回の記事は、社内の勉強会で私の方から補足説明したことを記事に残したものとなります。
「CI/CD」という言葉の説明や、CI/CDツールの具体的な使用方法に関する記事は多く見つかりますが、ツールが使われるようになった経緯(過去の作業手順)に触れた記事は少ないと感じましたので執筆しました。

何かの参考になれば幸いです。

EmEditorで巨大ファイルを開く(サクラエディタとの性能比較有り)

テキストエディタとしてはサクラエディタが良く使われると思います。
しかし、サクラエディタで重いファイルを開こうとして時間がかかってしまった、ということもあると思います。

そこで役立つのが、EmEditorです。
EmEditorは、サクラエディタとほぼ同時期(2000年頃)に生まれたWindows用のテキストエディタです。
サクラエディタと比較すると、巨大ファイルを開く時の速さに定評があります。

EmEditorはこちらからダウンロードできます。
有料版もありますが、今回の用途であれば無料版の「EmEditor Free」で十分です。
https://jp.emeditor.com/#download


参考までに、実際にどれほどの差があるのかを計測しましたので、計測結果を公開します。
先に結論を書くと、今回の計測では、EmEditorの方が40倍以上ファイルを早く開けるという結果になりました。

【動作環境】

  • OS:Windows8.1 64bit
  • CPU:Inter(R) Core(TM) i5-4210U CPU @ 1.70GHz 2.40GHz
  • メモリ:8.00GB
  • ディスク:SSD 128GB
  • EmEditorのバージョン:Version 21.6.1
  • サクラエディタのバージョン:Ver. 2.2.0.1

【開閉対象のファイル】

・約170MB(179,148,566バイト)

【計測結果】

・EmEditor(Free版)

サクラエディタ


いかがでしたでしょうか。

今回はちょっとした作業テクニックの紹介でした。
ファイル編集に関しては、サクラエディタ以外のテキストエディタはあまり使われないと思いますが、今回紹介した通り、他のテキストエディタを併用すると作業を効率化できる場合があります。

このようなちょっとした小ネタも今後取り上げていきたいと思います!

プログラムリリース時のコンティンジェンシープラン

コンティンジェンシープランとは、想定外の事態が起きた時に備えて事前に定めておく対応策のことです。
この記事では、プログラムのリリース時に定めておくべきコンティンジェンシープランについて、具体的に述べていきます。


プログラムのリリース作業は、事前に定められた一定の時間内に、プログラムを入れ替えて稼働確認を行う、という作業です。
例えば、特定の日の22:00-24:00をメンテナンス時間として事前に通知し、メンテナンス時間中はシステムの開放を止めてプログラム入れ替えと稼働確認を行う、というような作業を指します。

リリース作業時における主な想定外の事態は、稼働確認での不具合の発見です。
不具合を発見した時に備えて、以下のようなコンティンジェンシープランを事前に用意しておくべきです。

1.切り戻し作業の手順の用意と実施

新しくリリースしたプログラムに不具合が存在していたとしても、リリース時間内に元のプログラムに戻して稼働可能な状態に戻せば、利用者にはリリース前と変わらない機能を提供することができます。
リリースによるサービス水準の低下を防ぐという意味では、最も確実な対応策となります。
ただし、切り戻し作業自体にリスクが存在する(切り戻し作業を失敗し、戻せなかったり、より自体が悪化したりする可能性がある)ため、切り戻し作業を行う可能性があるのであれば、作業手順を事前に確立させる必要があります。
データの移行を伴う場合は、データの事前のバックアップとその戻しも必要になるので、特に注意が必要です。

2.サービス水準の低下を許容する方針の検討

切り戻し作業を行うのが最も確実ではあるのですが、発見された不具合が軽微なものであれば、その不具合を許容した上で戻さずにリリース作業を完了させる手もあります。
また、法律改正への対応のような、外部の変更に応じた対応の場合は切り戻し作業の実施自体が難しくなる(自社の判断だけでは切り戻し作業ができなくなる)ため、この場合も不具合を許容、最悪の場合は機能制限を加えた上でリリース作業完了させる必要が出てくることが多いです。

不具合を許容するかどうかの判断はその時々で柔軟に判断する必要がありますが、それを誰が判断するのか(作業時の責任者は誰なのか)は事前に決めておくべきです。
また、機能制限のような作業を行う可能性があるのであれば、その作業手順も事前に確認・確立させる必要があります。

3.切り戻し等の作業を開始するタイミングの確認

稼働確認で不具合が発見されたとしても、リリース時間内に修正できるのであれば、修正するに越したことはありません。
また、切り戻しを行うのかサービス水準の低下を許容するのかの判断が必要になる可能性もあります。

このように、不具合が発見されたとしても、切り戻しの行わない、という判断をすることがあります。
しかし、切り戻し作業にも時間が必要なので、その判断をいつまでに行うのか、ということは事前に決める必要があります。

例えば、24:00までにサービスを再開する必要があり、切り戻し作業に(余裕を見て)30分かかる場合、切り戻しを行うかどうかの判断は23:30までに行う必要があります。
23:30までに修正が完了しなかったり、サービス水準低下の許容の判断ができなかったりするのであれば、安全側に倒すために23:30を迎えた瞬間に切り戻し作業を開始するべきです。


いかがでしたでしょうか。

今回は、後輩に指導したことを記事として残しました。
記事に書いたことは、保守作業に携わるエンジニアであれば意識するべきことです。
大規模なシステムでは書類の形でプランを作る必要がありますし、小規模なシステムであっても関係者間で事前に認識を共有しておくべきです。

指導した内容はこれからも記事として残すようにしていこうと思います!

アイデアを引き出すのに使えるマクドナルド理論とは

「マクドナルド理論」と呼ばれる心理学のテクニックの紹介です。

あるテーマについて誰もアイデアを発言しない時に、すぐに思いつく限りで最低のアイデアを発言すると、皆がアイデアを発言し始める、というテクニックです。
昼食を決める時に「マクドナルドに行きたい」と言うと他のメンバーがより良いアイデアを発言し始める、という話が「マクドナルド理論」の由来です。
(マクドナルドが本当に最低のアイデアなのかどうかは置いておいて)

なぜこれでアイデアを発言するようになるのかは定かではありませんが、以下のような理由があると思っています。

  • 最低のアイデアで決まってしまうのを避けたい、という動機が生まれる
  • (取るに足らないかもしれない)自分のアイデアを発言しても良い、という安心感が生まれる

なお、ブレーンストーミングのようにメンバー全員でアイデアの数を稼ぐ必要があるような場面でなければ、あえて最低のアイデアを発言することに拘る必要はないと思っています。
とにかくアイデアを発言すれば、そのアイデアが許容できるものであればすんなり通りますし、最低のアイデアであればマクドナルド理論で対案を発言してくれます。
日々の業務で生産性を上げたいのであれば、アイデアの良し悪しに関わらずとりあえず口火を切って、お互いに悩む時間を減らすことが大事だと考えています。


いかがでしたでしょうか。

今回は、私も使うことがある心理学のテクニックの紹介でした。
心理学のテクニックの中には仕事で使えるものも少なくないので、また紹介したいと思います!