大規模な1C-Bitrixプロジェクトで心配を止めてGITにコミットし始めた方法

長い間、大規模な1C-Bitrix Webプロジェクトで管理者マネージャー（ある種のコーチ）として働く機会がありました：さまざまな国のさまざまな持株組織、Oracleデータベース、Webクラスターエディター、100 GBを超えるファイル、数年の歴史を持つ40以上のサイト、カーネル、パラノイアセキュリティモードの多くの更新に耐えたカーネルの20以上の編集、および...バージョン管理のヒントなしで戦闘サーバーの「ハンズオン」機能への直接変更...

非常に悲しい写真で、多くの「産業事故」を引き起こし、次の事件の後に修正が命じられました。



この記事では私の経験について説明しますが、主にバージョン管理システムを使用したことがなく、どこから始めればよいかわからない小規模なインターネットプロジェクトの所有者に役立ちます。



実際、私たちのトラブルはすべて2つの主な理由によるものです。

1. 大きなプロジェクトは、狭いゲージの鉄道に沿って明るい未来に全速力で駆けつけており、この時点でその下のレールを変更するのは少し困難でした。
2. バージョン管理システムと特にGITに関する膨大な量の文献がありますが、ほとんどすべてがスクリプトと明確なガイドラインの欠如に苦しんでいます。 たとえば、壮大なPro Gitは個々の機能と操作を完全に説明していますが、この富をどこから使い始めるかについてはほとんどわかりません。

物語はいくつかの部分に分けられます。

• 状況の説明
• ツール
• 説明書
  
  
  • 3.1リポジトリの初期化
  • 3.2ローリングタスクの更新
  • 3.3毎日の変更をコミットする（一日の終わり）
  • 3.4ロールバックの変更
• おわりに
• よくある質問

パート1-状況の説明

私は顧客の領域に直接位置しており、顧客と開発者の間の一種のジャンパーとして機能します。



お客様の優れたセキュリティガードは、何でも置き換えることができるすべてのものへのアクセスを制限します。

おそらく、私と開発者がSSH / FTPアクセスを持っていれば、この記事は決して登場しなかったでしょう（そして、その背後に潜む問題ははるかに少なかったでしょう）。

ただし、純粋に形式的には2つの方法で変更を行うことができるため、そのようなアクセスはありませんでした。

• 1C-Bitrix管理パネルを介してリモートで
• 顧客の領域で直接（厳密な監督の下で）

そのため、一部のタスクがロールオーバーされたときに、開発者マネージャーから定期的に電話を受けました。

アレクセイ、ここでタスクXXXをロールしたい。 init.phpを保存してください

当然のことながら、「あなたは決して知らない」が時々来て、指定されたファイルを復元する要求はチェーン全体に行き、その時点でサイトは利用できませんでした...



同様に、セントラルリポジトリ（GitLab）へのアクセスは、作成された時点では、お客様の領域に完全に制限されていました。 これにより、GITの実装に重要な制限が生じます。

• 開発者は顧客のサーバーからリポジトリを取得できません（手で.gitフォルダーをコピーする場合のみ）
• 開発者はGITを使用して更新をロールできません。 ロールバックは手動で行われます。

お客様と開発者のバージョン管理システムは、実質的に相互に分離されています（1C-Bitrix管理パネルを介した手動モードでのみ通信が行われます）。



また、管理アクセス（1C-Bitrixの1グループ）には時間が制限されています。 データベースレベル（Oracle）で私と開発者に9.00で権利を配布し、17.50モスクワ時間で選択する特別なスクリプトがあります。



これは悪夢です。 コメントでこれを思い出さないでください。 =）

パート2-ツール

2.1サーバー

Prodはメインの戦闘サーバーです。



Battle Serverに加えて、Headsの指示で2つのコピーが作成されました。

• テスト -リクエストに応じて再作成できます（他の部門の人が関与する必要があるため、プロセスは時間がかかります。推定実装期間は1日です）。 サーバーには、顧客と開発者のネットワークからのみアクセスできます。
• Prelive - 1日に 1回（夜間）自動的に再作成され、行われたすべての変更を上書きし、作成時にBattle Serverの現在のバージョンを取得します。 サーバーには、顧客と開発者のネットワークからのみアクセスできます。

私と開発者の両方にとって、3つすべてのサーバーへのアクセスはhttps経由のみです （この場合、証明書は自動的に1C-Bitrixにログインします）。

SSH / FTPアクセスは、私の直属の上司とのみです。 =（

GitLab - GitLabをデプロイするための別個のサーバーで、中央リポジトリとして使用されます。 サーバーは、直接IPを介してお客様のネットワークからのみアクセスできます（この記事の詳細については172. ***。***。61と仮定しますが、実際には、たとえばgithub.comなどの任意のIPまたはドメインを使用できます） 。

3つのWebサーバー（Prod / Test / Prelive）はすべてGitLabにsshアクセスできます。

http経由でのみGitLabにアクセスできます（実際、リポジトリの作成/削除と、枝のある美しい画像しか見ることができません）。

DEV-開発者のサーバーとワークステーションのセグメントの指定。 記事は考慮されません。 セグメントからのすべての変更は、私または開発者が1C-Bitrix管理パネルを通じて手動でお客様のサーバーに転送します。



最初のタスクロールアップスキームでは、チェーン全体を渡す必要がありました。

DEV→TEST→PRELIVE→PROD

タスクが戦闘に入る前に、最終チェックは「最も関連性の高い」プレリュードで行われることになっていた。 スキームは当然非常に退屈でほとんど役に立たないことが判明しました。

現時点では、タスクのチェックに2台のサーバーを使用することに賛成しました（テストでは長いチェックが必要で、Preliveではすぐにチェックされます）。

DEV→TEST / PRELIVE→PROD

コードは、セントラルリポジトリ（GitLab）を介してのみ顧客セグメントの1つのサーバーから別のサーバーに転送されるため、ロールアップスキームは次のように表すことができます。

2.1.1サーバー上のGIT

システム管理者によってインストールされます。 残念ながら、このトピックに関して有用なことは何も言えません（質問は私の能力を超えています）。

SSHキーの生成以外の特別な操作はありません（サーバーと中央リポジトリ（GitLab）間の通信用）。

手順は簡単にグーグルで検索できます。または、GitLabヘルプセクションに記載されています。

2.1.2サーバー上のWebコンソール（git_console.php）

前述のように、私も開発者もサーバーにSSHアクセスできないため、GITコマンドを送信するには、ブラウザーにコンソールを実装する別のスクリプトをインストールする必要がありました。

彼に感謝しますElfet （ Habré のコンソールに関する記事 ）

非常に小さな変更を加えました。

• 彼らは、サーバー自体の開発者がアクセスできないディレクトリにコンソール自体を配置します（そのため、開発者も私も、潜在的な攻撃者もコンソールのコードを変更できません ）。 同時に、カーネルに、管理者が使用できるgit_console.phpファイルを配置します。これにより、腸からのスクリプトが単純に接続されます。
• スクリプト設定では、コマンドの実行に制限が設けられました（git、pwd、cdのみ）。
• コンソールの背景色を変更しました（テスト-緑、プレライブ-グレー、製品-黒）。 これは、2、3人が喜んでタスク「not there」を開始した後に行われました =）
• 彼らは、証明書によるアクセス制限を追加しました（つまり、すべての管理者がコンソールにアクセスできるわけではありません。テスト期間中、私はアクセスのみを持っていました。

このソリューションの重要な利点は 、コンソールの自律性です！ つまり 開発者がinit.phpを変更してペンのストロークに失敗したサイトを設定した場合でも、コンソールは動作し（1C-Bitrixを使用しないため）、開発者はロールバックできます。

2.1.3リポジトリ構造

残念ながら、システム内のすべてのサイトがバージョン管理下にあるわけではなく、ホールディングの「ヘッド」のみです。 これにより、特定の不便と問題が発生します（たとえば、開発者が娘の1人に対してカーネルを修正する場合など）が、これは基本的にこれらのサイトの所有者自身が「地上」で抱える問題です。 おそらく将来的には、オーバーヘッドにもかかわらず、GITにも追加されるでしょう。

リポジトリの実際の構造のスキーム（名前とアドレスは部分的に消去されます）：



構造に見られるように：

• カーネルは別のディレクトリにあります
• 一部のサイトのフォルダは、「意味に従って」個別のディレクトリにグループ化されます
• 一部のサイトには独自の個人ディレクトリ/ローカル/
• 一部のサイトにはグループディレクトリ/ローカル/
• 一部のリポジトリにはサブモジュール（リポジトリ内のリポジトリ）があります-これらは通常、完了後にめったに更新されない特別なプロジェクトですが、ロジックとコンテンツの両方に大きな違いがあります（多くの場合、.gitignoreの大幅に異なるルールが適用されます）。 したがって、それらは、おnotを作成しないように、別々に取り出されます。

300 MBを超えるリポジトリはありません（最悪の日でも）。

これは、特定の種類のコンテンツ（PDF、avi、jpgなどのバイナリファイル）を.gitignoreの必要性とそれに対応する禁止なしにそのようなリポジトリに含めないという政治的決定によって達成されました。

2.1.4ドキュメント

この記事のすべての写真（もちろんKdPVを除く）は、お客様、私、および開発者が利用できる特別なリソースにあるドキュメントから取得されます。

最初（テスト運用期間）、ドキュメントのドラフトがマシンに保存されていましたが、今ではチーム全員がアクセスできるようにすべてのドキュメントが公開されています。

パート3-手順

だから、私たちは最も興味深いことに到達しました。

パート1で書かれたすべてが純粋にコンテキストを作成するためのもので（経験豊富なユーザーの心をつかむため）、パート2でさらに質問を深めることです（私たちの大きなプロジェクトのように、地平線に急速に近づいている人たちのために）イベント）、次にパート3-これらは、私が個人的に開始するのに十分ではなかった指示の基本的な例にすぎません。

GITを使用しなかったが、開始したい人（共有ホスティングに小さなオンラインストアがある場合でも）がGITに技術サポートを依頼し、以下で説明するスクリプトを使用してGitHubまたはBitBucketを中央リポジトリとして使用できることを願っています仕事を始めましょう。 そしてその過程で、彼らはすでにPro Gitのドキュメントを研究し、作業方法を適合させ、より柔軟で完璧なものにすることができます。

上記のすべてが1日以上で生まれました。 しかし、それがようやく現れたときでさえ、疑問はこの富をすべて使用する方法に留まりました。

以下のすべての指示は血で書かれ、それから私自身が「自分のために」書いたものです。

3.1リポジトリの初期化

3.1.1 Prodでのリポジトリの初期化（およびProd / Preliveの再構築）

最も簡単で正しい方法。

これは、バトル用のリポジトリを作成してから、サイト全体（リポジトリを含む）をバトルからTest and Reliveにコピーすることにあります。

たとえば、ディレクトリ/ local /（複数のサイトに共通）

Webコンソール（PROD上）-https：//********.ru：1119 / bitrix / admin / git_console.php

cd /u-app/bitrix/Apache/htdocs/site/******/local/



（他の場所のPress Serviceサイトのディレクトリ/ local / commonに移動します）

pwd



現在のディレクトリを確認します（場所を確認します）

git status



-GITステータスを確認します（リポジトリが表示されないはずです）

.gitignoreを配置します（付録のサンプルを参照）

git init





git config user.name "Zadoiny Alexey"





git config user.email "aleksey.zadoiny@******.ru"





git add -A .





git commit -m 'initital'





レポジトリがGitLabで作成されていない場合（local-******という名前で）作成します

git remote add origin git@172.***.***.61:Alexey.Zadoiny/local-******.git





git push -u origin master

リポジトリを作成したら、.htaccessファイルを

次のコンテンツ：

すべてを拒否

3.1.2製品上のリポジトリの初期化（および空のTEST / PRELIVEへの移植）

なぜこれが必要ですか？ たとえば、テストサーバーとバトルサーバーは既に作成および構成されており、近い将来それらの間で同期を行うことはできません。

同期の対象ではないが必要なファイルの数が少ないことが重要です（つまり、データベース接続ファイルのみが同期されていないため、この方法はカーネルに適していますが、多くのコンテンツがある場合は公開部分には適していません）リポジトリから除外されるバイナリファイル、それ以外の場合は3.1.3項を参照

3.1.3 Prod上のリポジトリの初期化（および空でないTEST / PRELIVEへの移植）

なぜこれが必要ですか？ たとえば、テストおよびバトルサーバーは既に作成および構成されており、近い将来それらの間の同期は不可能であり、ディレクトリにはバージョン管理システムを使用して同期されない大量のコンテンツが含まれます（たとえば、バイナリコンテンツファイル：pdf、jpg、swf、avi、など）

3.1.4 Prodのサブモジュールリポジトリの初期化（および空でないTEST / PRELIVEへの移植）

サブモジュールの難しさは、既存のエコシステムに変更を加える必要があるという事実にあります（つまり、リポジトリが既に存在し、突然、「 ええ、いや、親愛なる、フェンスがあり、Vasyaはフェンスの後ろに住んでいます！」 「）

特に、いくつかの機能を最初にデプロイしてコミットする場合、作成したすべてのファイル/ディレクトリを削除して、この場所にサブモジュールを作成する必要があります（ このトピックに関するTOSTERの質問 ）。

3.2ローリングタスクの更新

最初に、このプロセスはスキームに従って行われることになっていたことを思い出させてください。

DEV→TEST→PRELIVE→PROD

そのため、更新スキームには11のメインステップと4つの追加ステップが含まれ、いくつかのブランチがありました。



スキームは、

DEV→TEST / PRELIVE→PROD





ご注意 実際、すべての指示には、1つの住所（cd）ではなく、すべての住所のリストが記載されたプレートがあります。 つまり アクションを実行するときに、いずれか1つを選択して全体をコピーできます（特定のレポのディレクトリを覚えさせないでください）。



簡潔にするため、簡潔にするためにどこでも1つのアドレスを使用します（ほとんどの新しいGITユーザーはすぐに多くのリポジトリを操作する必要はないと考えているためです）。



各ステップは独立した自律的なものと見なされるため、リポジトリディレクトリへの移行から始まります。 プロセスが中断しない場合、命令のこのセクションは単純に無視できます。

3.2.0タスク更新のロールバック-ステップ0

cd /u-app/bitrix/Apache/htdocs/bitrix/



-プロジェクトフォルダーに移動します。 pwd



自分自身を確認する

git status



status-コミットされていない変更はありません。

git log



log-最後のコミットは、中央のGitLabリポジトリのMasterブランチの最後のコミットに対応する必要があります

git log



最後のコミットが表示されなかった場合は、ステップ3.4に進み、現在の状態をバトルからテスト/再現までローリングした後、手順を最初から開始します。

Nakat-何らかの手段（FTP、管理パネル）で機能するタスクをテスト/再現します。

3.2.1タスク更新プログラムのロールアップ-ステップ1

cd /u-app/bitrix/Apache/htdocs/bitrix/





git add -A .





git commit -m 'TIKET ######'





git push origin master:TIKET_######





変更をコミットし、開発ブランチ（テスト/リライブサーバーのウィザード）から中央リポジトリのタスクブランチに送信します。

3.2.2タスク更新のロールバック-ステップ2

cd /u-app/bitrix/Apache/htdocs/bitrix/





git status





git add -A .





git commit -m 'Prod changes ##'





git push origin master





戦闘ステータスを確認してください。

バトルステータスが変更された場合（およびテスト/リリースがより不適切な状態にある場合）、変更をコミットし、同期のために中央リポジトリに送信します。

変更がない場合は、手順4に進みます。

3.2.3タスク更新のロールバック-ステップ3

cd /u-app/bitrix/Apache/htdocs/bitrix/





git pull origin master





Test / Reliveのタスクのロールアップ中に戦闘が変更された場合（ステップ2を参照）、（中央リポジトリを介して）戦闘の変更をTest / Reliveにロールし、変更をモデレートする必要があります。

GITが単独でブランチをマージできない場合（たとえば、同じファイルの変更により競合が発生する場合）、競合を手動で解決する必要があります。

ステップの最後に→ステップ1に戻ります。

3.2.4タスク更新のロールバック-ステップ4

cd /u-app/bitrix/Apache/htdocs/bitrix/





git pull origin TIKET_######





中央リポジトリからバトルにタスク更新をロールします

3.3毎日の変更をコミットする（一日の終わり）

残念ながら、上記のプロセスにも関わらず、2つの主な理由により、戦闘には常に変化があります。

• バトルサーバーの公開部分のファイルを変更するアクセス権を持つコンテンツエディターが多数あります（当然、権限が制限されており、PHPコードを編集するアクセス権はありませんが、htmlマークアップを変更できます）。
• Daughtersのタスクがあり、コア/ bitrix /にしばしば影響します（規則として、テンプレートとコンポーネントが表示または変更されます）

したがって、営業日の終わりに毎日（そして、17.50モスクワ時間後の記事の冒頭から覚えているように、開発者と私はバトルでphpを編集する能力を失います）私はタスクの外で行われたすべての編集をまとめてコミットします。



このプロセスは、戦闘での変更のコミットとまったく同じです（3.1.2を参照）。

cd /u-app/bitrix/Apache/htdocs/bitrix/





git status





git add -A .





git commit -m 'Prod changes ##'





git push origin master

3.4ロールバックの変更

1. 変更をロールバックする必要がある状況は3種類あります（状況が悪化するため）。
2. テスト/リライブのロールバック（エラーが発生したか、タスクが正常に検証されたかは関係ありません-「サイトを解放」する必要があります。テスト/リライブの変更は必要ありません）
3. GITを介した軽微なエラーのバトルへのロールバック（キーワードは重要ではありません。たとえば、GitLabでの分析にはバージョン履歴が重要ですが、バトルに安定したバージョンを戻す必要があります。FRESH編集に対してのみ実行されます）
4. 重大なエラーの戦いへのロールバック（シリーズ「 シェフ、すべてがなくなった!!!! 1111ワンウェイ 」の状況、プロジェクトのパフォーマンスがGitLabの美しいストーリーよりも重要な場合）

3.4.1テスト-最後の安定状態へのロールバック

「頭に浮かぶ」というタスクを持つテストサーバーでの作業は実行されません。 このため、開発者には開発環境があります。顧客に引き渡す前にテストするためだけにここに来ます。したがって、無菌状態は履歴よりも重要です（そのため、フラグは硬く、チェックアウトなどではなくリセットされます）。

git reset --hard HEAD







複数のコミットをロールバックする必要がある場合は、GitLabから特定のコミットのハッシュを取得してロールバックします。

git reset --hard #HASH#



3.4.2ファイト-膨張したタスクがエラーを引き起こします（GIT経由で発生）

編集によってサーバーが配置されず、100％が最後のコミットに付属し、2か月前に作成されておらず、既に同化されていて、他のタスクとの依存関係が作成された場合、編集をキャンセルするカウンターコミットを作成できます。

利点は、この編集の履歴をGitLabに保存し、開発者（アクセスできる場合）がもう一度コミットを調べ、頭を動かすことができることです。 はい。コミットがGitLabマスターブランチに既に到達している場合、問題はありません。

編集が戦闘ですぐに行われた場合（誰が手を離すべきか？）、この戦略では、最初にコミットする必要がありますが、これは明らかに合理的ではありません。



git revert HEAD







前回の変更を破棄して、カウンターコミットを作成します。

3.4.3戦い-編集が戦いを壊した（完全に）

すべてが非常に悪い場合（サーバーが嘘をついているか、または「非常に重要な機能」がずっと前に壊れていたことが突然判明した場合、特に行く場所はありません：

git reset --hard HEAD







複数のコミットをロールバックする必要がある場合は、GitLabから特定のコミットのハッシュを取得してロールバックします。

git reset --hard #HASH#







このようなロールバックの結果、破棄されたコミットがGitLabのmasterブランチに既にヒットしていることが判明した場合、順序を復元するには、GitLabのリポジトリ全体を削除して再作成する方が簡単なことがよくあります。 =）

おわりに

説明したシナリオは非常に単純です。 これは同時に長所と短所です。

• 利点 -初心者のGITユーザーでもバージョン管理システムを使用できます（休暇中に2週間上司でテスト済み）
• 欠点は、経験豊富なユーザーが、より柔軟で興味深いシナリオを見て、一連の単純なアプリケーションルールに形式化するのが難しいことです。 そのため、開発と実装が成功した後、 Pro Gitの本を読むことをお勧めします。

ただし、このような限られたツールキットでも、GitLabでこのような素晴らしい写真を観察できます。





いくつかのコミットは、私のルールに従って名前が付けられていません。これは、タスクがロールオーバーしたときに、開発者がTest / Preliveサーバーの機能をすばやく設定した結果です。 そのような場合、TIKET _ ###### Patch _ ##（チケット番号とパッチシリアル番号）を作成して、トラッカーが関連するタスクを簡単に識別できるようにしました。





一部のタスクは、開発者ではなく、私によって直接実装されます。 この場合、TiketではなくTaskから呼び出し、別の会計システムの関連タスクのIDを示します。



実際、そのような枝や交差点はまったく素晴らしいものではありません。 クールに見えますが、実際には、チェックのために1週間または1か月延期されたすべてのタスクは、誰かにhemo核を作成し、それがすべてを統合します。

何かが壊れているわけではありません（ただし、GITで修正できない競合が数回あったため、解決しなければなりませんでした）。 しかし、それはあなたを緊張させます。