تمرین‌های DevOps کار می‌کنند. زمانی که زمان نصب انتشار را 10 برابر کاهش دادیم، خودمان به این موضوع متقاعد شدیم. در سیستم FIS Profile، که ما در VTB از آن استفاده می کنیم، نصب اکنون به جای 90 دقیقه 10 دقیقه طول می کشد. زمان ساخت انتشار از دو هفته به دو روز کاهش یافته است. تعداد نقایص اجرای مداوم تقریباً به حداقل کاهش یافته است. برای دور شدن از «کار دستی» و از بین بردن وابستگی به فروشنده، باید با عصا کار می‌کردیم و راه‌حل‌های غیرمنتظره پیدا می‌کردیم. در زیر برش، داستان مفصلی در مورد چگونگی ایجاد یک توسعه داخلی کامل وجود دارد.
پیش درآمد: DevOps یک فلسفه است
در طول یک سال گذشته، ما کارهای زیادی را برای سازماندهی توسعه داخلی و اجرای شیوه‌های DevOps در VTB انجام داده‌ایم:
- ما فرآیندهای توسعه داخلی را برای 12 سیستم ایجاد کردیم.
- ما 15 خط لوله راه اندازی کردیم که چهار مورد از آنها به تولید رسید.
- سناریوهای آزمایشی 1445 خودکار؛
- ما با موفقیت تعدادی از نسخه های آماده شده توسط تیم های داخلی را اجرا کردیم.
یکی از سخت‌ترین روش‌های سازماندهی توسعه و پیاده‌سازی رویه‌های DevSecOps، سیستم FIS Profile است - یک پردازشگر محصول خرده‌فروشی در یک DBMS غیرمرتبط. با این وجود، ما توانستیم توسعه را ایجاد کنیم، خط لوله را راه‌اندازی کنیم، بسته‌های منفرد غیرقابل انتشار را روی محصول نصب کنیم، و نحوه مونتاژ نسخه‌های منتشر شده را یاد گرفتیم. این کار آسان نبود، اما جالب و بدون محدودیت های آشکار در اجرا بود: این سیستم است - شما باید یک توسعه داخلی بسازید. تنها شرط استفاده از سی دی قبل از یک محیط تولیدی است.
در ابتدا، الگوریتم پیاده سازی ساده و واضح به نظر می رسید:
- ما تخصص توسعه اولیه را توسعه می دهیم و به سطح قابل قبولی از کیفیت از تیم کد بدون نقص فاحش دست می یابیم.
- ما تا حد امکان در فرآیندهای موجود ادغام می‌شویم.
- برای انتقال کد بین مراحل واضح، یک خط لوله را برش می دهیم و یکی از انتهای آن را به قسمت ادامه می دهیم.
در این مدت، تیم توسعه با اندازه مورد نیاز باید مهارت ها را توسعه دهد و سهم خود را در انتشارات به سطح قابل قبولی افزایش دهد. و بس، ما می توانیم کار را تکمیل شده در نظر بگیریم.
به نظر می رسد که این یک مسیر کاملاً کم مصرف برای رسیدن به نتیجه مورد نیاز است: اینجا DevOps است، اینجا معیارهای عملکرد تیم است، اینجا تخصص انباشته شده است... اما در عمل، تأیید دیگری دریافت کردیم که DevOps هنوز در مورد فلسفه است. و نه «پیوست به فرآیند gitlab، ansible، nexus و پایین‌تر فهرست».
پس از تجزیه و تحلیل مجدد برنامه اقدام، متوجه شدیم که در حال ساختن نوعی فروشنده برون سپاری در درون خود هستیم. بنابراین، مهندسی مجدد فرآیند به الگوریتم شرح داده شده در بالا و همچنین توسعه تخصص در کل مسیر توسعه برای دستیابی به نقش پیشرو در این فرآیند اضافه شد. ساده ترین گزینه نیست، اما این مسیر توسعه صحیح ایدئولوژیک است.
توسعه داخلی از کجا شروع می شود؟
این دوستانه ترین سیستم برای کار با آن نبود. از نظر معماری، این یک DBMS بزرگ غیرمرتبط بود که شامل بسیاری از اشیاء اجرایی مجزا (اسکریپت‌ها، رویه‌ها، دسته‌ها و غیره) بود که در صورت نیاز فراخوانی می‌شدند و بر اساس اصل یک جعبه سیاه کار می‌کردند: درخواست و مشکلات را دریافت می‌کرد. یک جواب. سایر مشکلات قابل ذکر عبارتند از:
- زبان عجیب و غریب (MUMPS)؛
- رابط کنسول؛
- عدم ادغام با ابزارها و چارچوب های اتوماسیون محبوب؛
- حجم داده ها در ده ها ترابایت؛
- بار بیش از 2 میلیون عملیات در ساعت؛
- اهمیت - تجاری - حیاتی.
در همان زمان، هیچ منبع کد منبع در سمت ما وجود نداشت. اصلا اسناد و مدارک وجود داشت، اما تمام دانش و شایستگی های کلیدی در کنار یک سازمان خارجی بود.
ما با در نظر گرفتن ویژگی ها و توزیع کم آن، تقریباً از ابتدا شروع به تسلط بر توسعه سیستم کردیم. آغاز شده در اکتبر 2018:
- مستندات و اصول تولید کد را مطالعه کرد.
- ما دوره کوتاه توسعه دریافت شده از فروشنده را مطالعه کردیم.
- تسلط بر مهارت های توسعه اولیه؛
- ما یک راهنمای آموزشی برای اعضای جدید تیم گردآوری کردیم.
- ما موافقت کردیم که تیم را در حالت "مبارزه" قرار دهیم.
- مشکل را با کنترل کیفیت کد حل کرد.
- ما یک غرفه برای توسعه سازماندهی کردیم.
ما سه ماه را صرف توسعه تخصص و غوطه ور شدن در سیستم کردیم و از ابتدای سال 2019، توسعه داخلی حرکت خود را به سمت آینده ای روشن، گاه به سختی، اما با اطمینان و هدفمند آغاز کرد.
انتقال مخزن و تست های خودکار
اولین وظیفه DevOps مخزن است. ما به سرعت در مورد ارائه دسترسی به توافق رسیدیم، اما لازم بود که از SVN فعلی با یک شاخه trunk به Git هدف خود با انتقال به مدلی از چندین شاخه و توسعه Git Flow مهاجرت کنیم. ما همچنین 2 تیم با زیرساخت های خاص خود به اضافه بخشی از تیم فروشنده در خارج از کشور داریم. من مجبور شدم با دو گیت زندگی کنم و از همگام سازی اطمینان حاصل کنم. در چنین شرایطی، آن دو شر کوچکتر بود.
مهاجرت مخزن بارها به تعویق افتاد؛ تنها در ماه آوریل و با کمک همکاران خط مقدم تکمیل شد. با Git Flow، ما تصمیم گرفتیم که برای شروع همه چیز را ساده نگه داریم و روی طرح کلاسیک با رفع فوری، توسعه و انتشار قرار گرفتیم. آنها تصمیم گرفتند که استاد (معروف به پرود مانند) را رها کنند. در زیر توضیح خواهیم داد که چرا این گزینه برای ما بهینه است. یک مخزن خارجی متعلق به فروشنده، مشترک برای دو تیم، به عنوان کارگر استفاده شد. طبق یک برنامه با مخزن داخلی همگام شد. اکنون با Git و Gitlab امکان خودکارسازی فرآیندها وجود داشت.
موضوع تست های خودکار به طرز شگفت انگیزی به راحتی حل شد - یک چارچوب آماده به ما ارائه شد. با در نظر گرفتن ویژگی های سیستم، فراخوانی یک عملیات جداگانه بخشی قابل درک از فرآیند تجاری بود و در عین حال به عنوان یک آزمون واحد عمل می کرد. تنها چیزی که باقی مانده بود آماده سازی داده های آزمایش و تنظیم ترتیب مورد نظر برای فراخوانی اسکریپت ها و ارزیابی نتایج بود. با تکمیل لیست سناریوها، که بر اساس آمار عملیات، بحرانی بودن فرآیندها و روش رگرسیون موجود، تشکیل شد، آزمایش های خودکار شروع به ظاهر شدن کردند. اکنون می توانیم ساخت خط لوله را آغاز کنیم.
چگونه بود: مدل قبل از اتوماسیون
مدل موجود از فرآیند پیاده سازی یک داستان جداگانه است. هر اصلاح به صورت دستی به عنوان یک بسته نصب افزایشی جداگانه منتقل شد. بعد ثبت نام دستی در Jira و نصب دستی روی محیط ها آمد. برای بسته های جداگانه، همه چیز واضح به نظر می رسید، اما با آماده سازی نسخه، همه چیز پیچیده تر شد.
مونتاژ در سطح تحویل های فردی انجام شد که اشیاء مستقل بودند. هر تغییری یک تحویل جدید است. از جمله، 60-70 نسخه فنی به بسته های 10-15 ترکیب اصلی نسخه اضافه شد - نسخه هایی که هنگام اضافه کردن یا حذف چیزی از انتشار و منعکس کننده تغییرات در فروش خارج از نسخه به دست می آیند.
اشیاء در تحویل با یکدیگر همپوشانی داشتند، به خصوص در کد اجرایی که کمتر از نصف آن منحصر به فرد بود. وابستگی های زیادی هم به کد از قبل نصب شده و هم به کدی که نصب آن به تازگی برنامه ریزی شده بود وجود داشت.
برای به دست آوردن نسخه مورد نیاز کد، لازم بود دقیقاً ترتیب نصب را دنبال کنید، که در طی آن اشیا به صورت فیزیکی بارها، حدود 10 تا 12 بار بازنویسی شدند.
پس از نصب دسته ای از بسته ها، مجبور شدم به صورت دستی دستورالعمل ها را برای مقداردهی اولیه تنظیمات دنبال کنم. انتشار توسط فروشنده مونتاژ و نصب شد. ترکیب انتشار تقریباً قبل از لحظه اجرا مشخص شد که مستلزم ایجاد بسته های "جداسازی" بود. در نتیجه، بخش قابل توجهی از ذخایر از عرضه به عرضه با دنباله خود «جداسازی» حرکت کرد.
اکنون مشخص است که با این رویکرد - مونتاژ پازل آزادسازی در سطح بسته - یک شاخه اصلی واحد معنای عملی نداشت. نصب بر روی تولید از یک و نیم تا دو ساعت کار دستی طول کشید. خوب است که حداقل در سطح نصب کننده ترتیب پردازش شی مشخص شده است: فیلدها و ساختارها قبل از داده ها و رویه ها وارد شده اند. با این حال، این فقط در یک بسته جداگانه کار می کرد.
نتیجه منطقی این رویکرد، نقص های نصب اجباری در قالب نسخه های کج اشیا، کدهای غیر ضروری، دستورالعمل های گمشده و تأثیرات متقابل اجسام بود که پس از انتشار به شدت برطرف شد.
اولین به روز رسانی: مونتاژ و تحویل را انجام دهید
اتوماسیون با انتقال کد از طریق یک لوله در این مسیر آغاز شد:
- تحویل نهایی را از انبار تحویل بگیرید.
- آن را روی یک محیط اختصاصی نصب کنید.
- تست های خودکار را اجرا کنید.
- ارزیابی نتیجه نصب؛
- خط لوله زیر را در کنار دستور تست فراخوانی کنید.
خط لوله بعدی باید وظیفه را در Jira ثبت کند و منتظر باشد تا دستورات در حلقه های آزمایشی منتخب توزیع شوند که به زمان اجرای کار بستگی دارد. ماشه - نامه ای در مورد آمادگی برای تحویل به یک آدرس مشخص. این، البته، یک عصا آشکار بود، اما من باید از یک جایی شروع می کردم. در می 2019، انتقال کد با بررسی محیط‌های ما آغاز شد. این روند آغاز شده است، تنها چیزی که باقی می ماند این است که آن را به شکل مناسبی در آوریم:
- هر اصلاح در یک شاخه جداگانه انجام می شود که مربوط به بسته نصب است و در شاخه اصلی هدف ادغام می شود.
- ماشه راه‌اندازی خط لوله، ظهور یک commit جدید در شاخه اصلی از طریق یک درخواست ادغام است که توسط نگهبانان تیم داخلی بسته می‌شود.
- مخازن هر پنج دقیقه یک بار همگام سازی می شوند.
- مونتاژ بسته نصب شروع می شود - با استفاده از اسمبلر دریافت شده از فروشنده.
پس از این، مراحل موجود برای بررسی و انتقال کد، راه اندازی لوله و مونتاژ در سمت ما وجود داشت.
این گزینه در ماه جولای راه اندازی شد. مشکلات انتقال منجر به نارضایتی در میان فروشنده و خط مقدم شد، اما در طول یک ماه بعد ما موفق شدیم تمام لبه های ناهموار را حذف کنیم و روندی را در بین تیم ها ایجاد کنیم. ما اکنون مونتاژ با تعهد و تحویل داریم.
در ماه آگوست، ما موفق شدیم اولین نصب یک بسته جداگانه را در تولید با استفاده از خط لوله خود تکمیل کنیم و از سپتامبر، بدون استثنا، تمام نصب بسته‌های غیر انتشاری جداگانه از طریق ابزار CD ما انجام شد. علاوه بر این، ما موفق شدیم به سهمی از وظایف داخلی در 40٪ از ترکیب انتشار با تیمی کوچکتر از فروشنده برسیم - این یک موفقیت قطعی است. جدی ترین کار باقی ماند - مونتاژ و نصب نسخه.
راه حل نهایی: بسته های نصب تجمعی
ما به خوبی فهمیدیم که نوشتن دستورالعمل‌های فروشنده یک اتوماسیون بسیار زیاد است؛ ما باید در خود فرآیند تجدید نظر می‌کردیم. راه حل واضح بود - جمع آوری یک منبع تجمعی از شاخه انتشار با تمام اشیاء نسخه های مورد نیاز.
ما با اثبات مفهوم شروع کردیم: بسته انتشار را با توجه به محتویات اجرای گذشته به صورت دستی مونتاژ کردیم و آن را روی محیط خود نصب کردیم. همه چیز درست شد، مفهوم قابل اجرا بود. در مرحله بعد، مشکل اسکریپت کردن تنظیمات اولیه و گنجاندن آنها در commit را حل کردیم. ما یک بسته جدید آماده کردیم و آن را در محیط های آزمایشی به عنوان بخشی از به روز رسانی کانتور آزمایش کردیم. نصب با موفقیت انجام شد، البته با طیف وسیعی از نظرات تیم اجرا. اما نکته اصلی این است که به ما مجوز داده شد تا در نسخه نوامبر با مونتاژ خود وارد تولید شویم.
در حالی که کمی بیش از یک ماه باقی مانده است، منابع دستچین شده به وضوح نشان می دهد که زمان در حال اتمام است. آنها تصمیم گرفتند که بیلد را از شاخه انتشار بسازند، اما چرا باید جدا شود؟ ما یک Prod مانند نداریم و شاخه های موجود خوب نیستند - کدهای غیر ضروری زیادی وجود دارد. ما نیاز فوری داریم که لایک های prod را کاهش دهیم، و این بیش از سه هزار commit است. مونتاژ با دست اصلاً یک گزینه نیست. ما اسکریپتی را ترسیم کردیم که در لاگ نصب محصول اجرا می شود و تعهدات را به شعبه جمع آوری می کند. بار سوم به درستی کار کرد و پس از "تمام فایل" شاخه آماده شد.
ما سازنده خودمان را برای بسته نصب نوشتیم و در عرض یک هفته تمام کردیم. سپس مجبور شدیم نصب کننده را از عملکرد اصلی سیستم تغییر دهیم، زیرا منبع باز است. پس از یک سری بررسی ها و اصلاحات، نتیجه موفقیت آمیز در نظر گرفته شد. در این بین، ترکیب انتشار شکل گرفت که برای نصب صحیح آن باید مدار آزمایشی را با مدار تولیدی تراز کرد و فیلمنامه جداگانه ای برای این کار نوشته شد.
طبیعتاً نظرات زیادی در مورد نصب اول وجود داشت، اما در کل کد کار کرد. و پس از نصب سوم، همه چیز خوب به نظر می رسد. کنترل ترکیب و کنترل نسخه اشیاء به طور جداگانه در حالت دستی نظارت می شد که در این مرحله کاملاً موجه بود.
یک چالش دیگر، تعداد زیادی از موارد منتشر نشده بود که باید در نظر گرفته می شد. اما با شاخه Prod مانند و Rebase، کار شفاف شد.
اولین بار، سریع و بدون خطا
ما با نگرش خوش بینانه و بیش از ده ها نصب موفق در مدارهای مختلف به انتشار نزدیک شدیم. اما به معنای واقعی کلمه یک روز قبل از مهلت مقرر، معلوم شد که فروشنده کار را برای آماده سازی نسخه برای نصب به روش پذیرفته شده تکمیل نکرده است. اگر بنا به دلایلی ساخت ما کار نکند، انتشار مختل خواهد شد. علاوه بر این، از طریق تلاش های ما، که به ویژه ناخوشایند است. راهی برای عقب نشینی نداشتیم. بنابراین، ما به گزینه های جایگزین فکر کردیم، برنامه های عملیاتی را آماده کردیم و نصب را شروع کردیم.
با کمال تعجب، کل انتشار شامل بیش از 800 شیء، اولین بار و تنها در 10 دقیقه به درستی آغاز شد. ما یک ساعت صرف بررسی گزارش‌ها برای یافتن خطا کردیم، اما هیچ کدام را پیدا نکردیم.
کل روز بعد در چت انتشار سکوت وجود داشت: هیچ مشکلی در پیاده سازی، نسخه های نادرست یا کد "نامناسب". حتی به نوعی ناخوشایند بود. بعداً نظراتی مطرح شد، اما در مقایسه با سایر سیستم ها و تجربه قبلی، تعداد و اولویت آنها به طرز محسوسی کمتر بود.
یک اثر اضافی از اثر تجمعی افزایش کیفیت مونتاژ و آزمایش بود. به دلیل نصب های متعدد نسخه کامل، نقص های ساخت و خطاهای استقرار به موقع شناسایی شدند. آزمایش در پیکربندی‌های رهاسازی کامل امکان شناسایی عیوب در تأثیر متقابل اجسامی را که در طول نصب تدریجی ظاهر نمی‌شدند را نیز ممکن ساخت. این قطعا موفقیت آمیز بود، به خصوص با توجه به مشارکت 57 درصدی ما در انتشار.
نتایج و نتیجه گیری
در کمتر از یک سال موفق شدیم:
- ایجاد یک توسعه داخلی تمام عیار با استفاده از یک سیستم عجیب و غریب.
- حذف وابستگی حیاتی فروشنده؛
- راه اندازی CI/CD برای میراث بسیار غیر دوستانه.
- بالا بردن فرآیندهای اجرایی به سطح فنی جدید؛
- کاهش قابل توجه زمان استقرار؛
- به طور قابل توجهی تعداد خطاهای اجرا را کاهش دهید.
- با اطمینان خود را به عنوان یک متخصص پیشرو در توسعه معرفی کنید.
البته، بسیاری از مواردی که شرح داده شده به نظر می رسد یک مزخرف است، اما اینها ویژگی های سیستم و محدودیت های فرآیندی است که در آن وجود دارد. در حال حاضر، تغییرات بر محصولات و خدمات نمایه IS (حساب‌های اصلی، کارت‌های پلاستیکی، حساب‌های پس‌انداز، امانی، وام‌های نقدی) تأثیر می‌گذارد، اما به طور بالقوه می‌توان این رویکرد را برای هر IS که وظیفه اجرای شیوه‌های DevOps برای آن تعیین شده است، اعمال کرد. مدل تجمعی را می توان با خیال راحت برای پیاده سازی های بعدی (از جمله موارد غیر انتشار) از بسیاری از تحویل ها تکرار کرد.
منبع: www.habr.com