تحديث عملية CI / CD: الإعداد والتخطيط

صورة

في عام 2020 ، ربما يكون من الصعب جدًا العثور على مشروع في وصف المكدس الذي لن يحتوي على إحدى الكلمات التالية: IaC ، الخدمات الصغيرة ، kubernetes ، عامل الميناء ، aws / azure / gcloud ، blockchain ، ML ، VR وما إلى ذلك. وهذا رائع! التقدم لا يقف ساكنا. نحن ننمو ، مشاريعنا تنمو معنا ، تظهر أدوات أكثر ملاءمة وعملية تحل المشاكل الحديثة.

مرحبا. لذلك أردت أن أبدأ هذه المقالة. ولكن بعد ذلك راجعت بعض الأشياء ، وتحدثت مع زملائي ، وأدركت أنني سأكون مخطئًا. لا تزال هناك مشروعات يبلغ عمرها أكثر من 15 عامًا بالفعل ، مع مديرين ومشاركين من المؤمنين القدامى ، وبالتالي فإن هذه المشاريع لديها مجموعة تقنية قديمة يصعب الاحتفاظ بها في حديقة حيوان موجودة. ولسبب ما ، لا يمكن تحديث هذا المشروع عالميًا (العميل هو بداية ، ولا يوجد تحديث ، والمشروع كبير جدًا ، وتأخر الترحيل ، أو أن الجميع سعداء بكل شيء) ، وعليك دعمه. أكثر إزعاجًا عندما لا يزال يتم تطوير مشروع مماثل بنشاط. إنها مثل كرة الثلج. يحتاج العميل والجمهور إلى ميزات ، ويتطلب الرمز التسليم ، وتتطلب الخوادم الاهتمام والرعاية ... ولكن حزمة Bitpack - لذلك توقفت بشكل عام عن دعم الزئبق. يقترح فقط مثل هذه الحالة للنظر فيها.

ما سيتم اعتباره: تحويل بوابة الزئبق ، ونقل CI من CruiseControl.NET إلى TeamCity ، من نشر البوابة إلى Octopus مع وصف صغير للعملية بأكملها.

تحول النص كثيرًا ، لذلك سيتم تقسيمه إلى أجزاء منفصلة لتسهيل الإدراك. سيكون هناك جدول محتويات.
الجزء 1: ما هو ، لماذا لا يبدو ، التخطيط ، القليل من باش. أود أن أسمي هذا الجزء شبه التقني.
الجزء 2: teamcity.
الجزء 3: نشر الأخطبوط.
الجزء الرابع: خلف الكواليس. لحظات غير سارة ، خطط للمستقبل ، ربما أسئلة متكررة. على الأرجح ، يمكن أن يطلق عليه أيضًا شبه تقني.

لن أسمي هذا دليلًا للتكرار لأسباب عديدة: الانغماس غير الكافي في عمليات المشروع بسبب ضيق الوقت ، وعدم كفاية الممارسة لمثل هذه الأشياء ، وموحد ضخم تترابط فيه جميع المشاريع الفرعية بشكل وثيق ، ومجموعة من الفروق الدقيقة الأخرى التي تجعلك تحترق ، وتتساءل ، وطرحها ، ولكن في أي حال من الأحوال لا يرجى. وأيضًا ، نظرًا لميزات المشروع (إنه فريد تمامًا) ، سيتم تخصيص بعض الخطوات حصريًا لهذه الحالة.

مقدمة كلاسيكية


كان لدينا مستودع زئبقي ، وأكثر من 300 وجبة غداء (مفتوحة!) ، و ccnet ، و ccnet + git أخرى (للنشر) ، ومجموعة كاملة من وحدات المشروع مع التكوينات الخاصة بنا والعملاء الفرديين ، وأربع بيئات ومجموعة كاملة من التجمعات في IIS ، بالإضافة إلى cmd البرامج النصية ، SQL ، أكثر من خمسمائة مجال ، وعشرين بناء ، وتطوير نشط بالإضافة إلى ذلك. ليس أن كل هذا كان ضروريًا ، لكنه نجح ، وكان غير مريح وطويل. الشيء الوحيد الذي أثار قلقي هو وجود مشاريع أخرى تتطلب اهتمامي. لا يوجد شيء في عملية العمل بمهام بهذا الحجم أخطر من نقص التركيز والانقطاع.

كنت أعلم أنه سيتعين علي الانتباه عاجلاً أم آجلاً لمهام أخرى ، ولهذا السبب قضيت الكثير من الوقت في دراسة البنية التحتية الحالية حتى لا تكون هناك مشكلات لم يتم حلها بعد ذلك على الأقل.

لسوء الحظ ، لا يمكنني تقديم وصف كامل للمشروع بسبب اتفاقية عدم الإفشاء ، لذلك سيتم النظر في النقاط الفنية العامة. سيتم أيضًا رسم جميع الأسماء المتعلقة بالمشروع. أعتذر عن اللطاخة السوداء على لقطات الشاشة.

واحدة من الميزات الرئيسية للمشروع هو أنه يحتوي على عدد من الوحدات التي لها جوهر واحد ، ولكنها تختلف في تكويناته. هناك أيضًا وحدات ذات نهج "خاص" ، تم تصميمها للموردين وخاصة العملاء الكبار. يمكن لوحدة واحدة أن تخدم أكثر من عميل واحد. يجب أن يُفهم العميل على أنه منظمة منفصلة أو مجموعة من الأشخاص الذين يمكنهم الوصول إلى وحدة معينة. يحصل كل عميل على إمكانية الوصول في نطاقه الخاص ، ولديه تصميمه الخاص وإعداداته الافتراضية الفريدة الخاصة به. يتم تحديد العميل من خلال المجال الذي يستخدمه.

يمكن تمثيل المخطط العام لهذا الجزء من المشروع على النحو التالي:


كما ترى ، يتم استخدام النواة نفسها في كل مكان ، ويمكن استخدامها.

أسباب ظهور المهمة لمراجعة وتحديث عمليات CI / CD:

  1. تم استخدام CruiseControl.NET كنظام بناء. العمل معه متعة مشكوك فيها من حيث المبدأ. تكوينات XML على شاشات متعددة ، ومجموعة من التبعيات وربط التكوينات مع بعضها البعض ، ونقص الحلول الحديثة للمشكلات الحديثة.
  2. يجب أن يكون لدى بعض المطورين (العملاء المحتملين) في المشروع حق الوصول إلى خوادم الإنشاء ، ويفضلون أحيانًا تغيير تكوينات ccnet التي لا يجب تغييرها. خمن ما سيحدث بعد ذلك. يجب أن يكون لديك إدارة بسيطة ومريحة للحقوق في نظام CI ، دون الابتعاد عن وصول المطورين إلى الخادم. ببساطة ، لا يوجد تكوين نص - لا يوجد مكان للتسلق بأيد مرحة.
  3. - … CCNET, git. (. ).
  4. , . , . 
  5. - , — ( ) .
  6. . ? ? ? .
  7. الاستخدام الأمثل للموارد والعملية القديمة لبناء وتقديم التعليمات البرمجية.

الشكل الوارد في الفقرة 3:


في مرحلة التخطيط ، تقرر استخدام Teamcity كنظام بناء ، و Octopus كنظام نشر. ظلت البنية التحتية "الحديدية" الخاصة بالعميل دون تغيير: خوادم مخصصة منفصلة للتطوير والاختبار والتدريج والإنتاج ، بالإضافة إلى خوادم البائعين (بشكل أساسي بيئات الإنتاج).

تم تزويد العميل بإثبات المفهوم على مثال إحدى الوحدات ، وتم كتابة خطة عمل ، وتم تنفيذ الأعمال التحضيرية (التثبيت ، التكوين ، إلخ). ربما لا يوجد معنى في وصف هذا. يمكن قراءة كيفية تثبيت مدينة الفريق على الموقع الرسمي. سوف أسهب في الحديث بشكل منفصل عن بعض المتطلبات المصاغة للنظام الجديد:

  1. سهولة الصيانة مع جميع العواقب (النسخ الاحتياطية والتحديثات وحل المشكلات ، إن وجدت).
  2. عالمية. من الناحية المثالية ، وضع مخطط عام يتم بموجبه تجميع جميع الوحدات وتسليمها ، واستخدامها كقالب.
  3. تقليل الوقت اللازم لإضافة تكوينات البناء الجديدة والصيانة. تتم إضافة / إزالة العملاء. في بعض الأحيان يصبح من الضروري عمل إعدادات جديدة. من الضروري أنه عند إنشاء وحدة نمطية جديدة يجب ألا يكون هناك أي تأخير في تكوين تسليمها.

عند هذه النقطة ، تذكرنا وقف دعم المستودعات الزئبقية باستخدام bitbucket ، وتمت إضافة الشرط لنقل المستودع إلى git مع الحفاظ على الفروع وتاريخ الالتزامات.

التحضير: تحويل المستودع


يبدو أن شخصًا ما قد حل هذه المشكلة بوضوح أمامنا وبدلاً منا. تحتاج فقط إلى إيجاد حل عمل جاهز. تبين أن التصدير السريع ليس بهذه السرعة. بالإضافة إلى ذلك ، لم تنجح. للأسف ، لا توجد سجلات ولقطات شاشة متبقية. الحقيقة هي أنه لم يستطع. لا يوفر Bitbucket المحول الخاص به (ولكن يمكن). زوجان من الأساليب غوغل ، وأيضا. قررت كتابة نصوصي الخاصة ، على أي حال هذا ليس المستودع الزئبقي الوحيد ، سيكون مفيدًا في المستقبل. سيتم عرض التطورات المبكرة هنا (لأنها لا تزال في نفس الشكل). منطق العمل يبدو كالتالي:

  1. نحن نأخذ التمدد الزئبقي كأساس. 
  2. نحصل على قائمة بجميع فروع المستودع الزئبقي. 
  3. نقوم بتحويل أسماء الفروع (بفضل Mercurial والمطورين للمساحات في أسماء الفروع ، والشكر الخاص للموسوم والشخصيات الأخرى التي تضيف الفرح إلى الحياة).
  4. ضع إشارات مرجعية (إشارة مرجعية زئبقية) وادفع إلى المستودع المتوسط. لماذا؟ لأن bitbucket ، ولأنه لا يمكنك إنشاء إشارة مرجعية بنفس اسم اسم الفرع (على سبيل المثال ، التدريج). 
  5. في مستودع (git) الجديد بالفعل ، قم بإزالة postfix من اسم الفرع وترحيل hgignore إلى gitignore. 
  6. ادفع إلى المستودع الرئيسي.

أوامر القيد حسب النقاط:

  1. $ cd /path/to/hg/repo
    $ cat << EOF >> ./.hg/hgrc
    [extensions]
    hggit=
    EOF
    
  2. $ hg branches > ../branches
    
  3. #!/usr/bin/env bash
    hgBranchList="./branches"
    sed -i 's/:.*//g' ${hgBranchList}
    symbolsToDelete=$(awk '{print $NF}' FS=" " ${hgBranchList} > sym_to_del.tmp)
     
    i=0
    while read hgBranch; do
      hgBranches[$i]=${hgBranch}
      i=$((i+1))
    done <${hgBranchList}
     
    i=0
    while read str; do
      strToDel[$i]=${str}
      i=$((i+1))
    done < ./sym_to_del.tmp
     
    for i in ${!strToDel[@]}
    do
      echo ${hgBranches[$i]} | sed "s/${strToDel[$i]}//" >> result.tmp
    done
     
    sed -i 's/[ \t]*$//' result.tmp
    sed 's/^/"/g' result.tmp > branches_hg
    sed -i 's/$/"/g' branches_hg
    sed 's/ /-/g' result.tmp > branches_git
    sed -i 's/-\/-/\//g' branches_git
    sed -i 's/-\//\//g' branches_git
    sed -i 's/\/-/\//g' branches_git
    sed -i 's/---/-/g' branches_git
    sed -i 's/--/-/g' branches_git
    rm sym_to_del.tmp
    rm result.tmp
    
  4. #!/usr/bin/env bash
    gitBranchList="./branches_git"
    hgBranchList="./branches_hg"
    hgRepo="/repos/reponame"
     
    i=0
    while read hgBranch; do
      hgBranches[$i]=${hgBranch}
      i=$((i+1))
    done <${hgBranchList}
     
    i=0
    while read gitBranch; do
      gitBranches[$i]=${gitBranch}
      i=$((i+1))
    done <${gitBranchList}
     
    cd ${hgRepo}
    for i in ${!gitBranches[@]}
    do
      hg bookmark -r "${hgBranches[$i]}" "${gitBranches[$i]}-cnv"
    done
     
    hg push git+ssh://git@bitbucket.org:username/reponame-temp.git
    echo "Done."
    
  5. #!/bin/bash
    # clone repo, run git branch -a, delete remotes/origin words to leave only branch names, delete -cnv postfix, delete default branch string because we can't delete it
    repo="/repos/repo"
    gitBranchList="./branches_git"
    defaultBranch="default-cnv"
    while read gitBranch; do   gitBranches[$i]=${gitBranch};   i=$((i+1)); done < $gitBranchList
    cd $repo
    for i in ${!gitBranches[@]}; do git checkout ${gitBranches[$i]}-cnv; done
    git checkout $defaultBranch
    for i in ${!gitBranches[@]}; do
        git branch -m ${gitBranches[$i]}-cnv ${gitBranches[$i]}
        git push origin :${gitBranches[$i]}-cnv ${gitBranches[$i]}
        git push origin -u ${gitBranches[$i]}
    done
    
  6. #!/bin/bash
    # clone repo, run git branch -a, delete remotes/origin words to leave only branch names, delete -cnv postfix, delete default branch string because we can't delete it
    repo="/repos/repo"
    gitBranchList="./branches_git"
    defaultBranch="default"
    while read gitBranch; do   gitBranches[$i]=${gitBranch};   i=$((i+1)); done < $gitBranchList
    cd $repo
    for i in ${!gitBranches[@]}; do
        git checkout ${gitBranches[$i]}
        sed -i '1d' .hgignore
        mv .hgignore .gitignore
        git add .
        git commit -m "Migrated ignore file"
    done
    

سأحاول شرح معنى بعض الإجراءات ، أي استخدام مستودع وسيط. في البداية ، في المستودع بعد التحويل ، تحتوي أسماء الفروع على postfix "-cnv". هذا يرجع إلى ميزة المرجعية زئبق. تحتاج إلى إزالة هذا postfix ، وكذلك إنشاء ملفات gitignore بدلاً من hgignore. كل هذا يضيف التاريخ ، وبالتالي يزيد من حجم المستودع (وغير معقول). كمثال آخر ، يمكنني الاستشهاد بما يلي: حاول إنشاء مستودع ، وادفع الالتزام الأول إلى 300 متر مع الكود فيه. ثم أضفه إلى gitignore ، وادفعه بدونه. سيبقى في التاريخ. الآن حاول إزالته من السجل (git filter-branch). مع عدد معين من عمليات التنفيذ ، لن ينخفض ​​حجم المستودع الناتج ، بل سيزيد. يتم حل هذا عن طريق التحسين ، ولكن لا يمكن بدؤه على bitbucket.يتم تنفيذه فقط عند استيراد المستودع. لذلك ، يتم تنفيذ جميع العمليات التقريبية باستخدام وسيط ، ثم يتم الاستيراد إلى عملية جديدة. كان حجم المستودع الوسيط في النهائي 1.15 جم ، وحجم 350 م الناتج. 

استنتاج


تم تقسيم عملية الهجرة بأكملها إلى عدة مراحل ، وهي:

  • التحضير (عرض توضيحي للعميل باستخدام مثال لبناء واحد ، وتثبيت البرامج ، وتحويل المستودعات ، وتحديث تكوينات ccnet الحالية) ؛
  • تكوين CI / CD لبيئة التطوير واختباراته (النظام القديم لا يزال يعمل بالتوازي) ؛
  • إعدادات CI / CD للبيئات المتبقية (بالتوازي مع "good" الموجودة) والاختبارات ؛
  • تطوير الهجرة ، انطلاقها واختبارها ؛
  • ترحيل الإنتاج ونقل المجالات من مثيلات IIS القديمة إلى جديدة.

ويجري حاليا استكمال وصف المرحلة التحضيرية المكتملة بنجاح. لم يتم تحقيق بعض النجاح الفخم هنا ، باستثناء أن النظام الحالي لم ينهار وتم ترحيل المستودع الزئبقي في git. ومع ذلك ، بدون وصف لهذه العمليات ، لن يكون هناك سياق لمزيد من الأجزاء الفنية. سيصف الجزء التالي عملية إنشاء نظام CI على أساس المدينة الجماعية.

All Articles