بیایید بحث کنیم که چرا ابزارهای CI و CI چیزهای کاملاً متفاوتی هستند.
CI قصد دارد چه دردهایی را حل کند، این ایده از کجا آمده است، آخرین تأییدیه‌هایی که کار می‌کند چیست، چگونه بفهمیم که شما یک تمرین دارید و نه فقط جنکینز را نصب کرده‌اید.
ایده تهیه گزارش در مورد Continuous Integration یک سال پیش، زمانی که برای مصاحبه می رفتم و دنبال کار می گشتم، به وجود آمد. من با 10-15 شرکت صحبت کردم، فقط یکی از آنها توانست به وضوح پاسخ دهد که CI چیست و توضیح دهد که چگونه متوجه شدند که آن را ندارند. بقیه در مورد جنکینز مزخرفات نامفهومی می گفتند :) خب، ما جنکینز داریم، می سازد، CI! در طول گزارش، من سعی خواهم کرد توضیح دهم که Continuous Integration واقعا چیست و چرا جنکینز و ابزارهای مشابه رابطه بسیار ضعیفی با آن دارند.
بنابراین، با شنیدن کلمه CI معمولاً چه چیزی به ذهن شما خطور می کند؟ اکثر مردم به جنکینز، گیتلب CI، تراویس و غیره فکر خواهند کرد.
حتی اگر آن را در گوگل جستجو کنیم، این ابزارها را در اختیار ما قرار می دهد.
اگر با سوال کردن آشنا هستید، بلافاصله پس از فهرست کردن ابزارها، به شما خواهند گفت که CI زمانی است که در یک Pull Request برای یک commit، تست هایی را ایجاد و اجرا می کنید.
Continuous Integration در مورد ابزارها نیست، نه در مورد مجموعه هایی با آزمایش در یک شاخه! یکپارچه سازی پیوسته تمرین ادغام بسیار مکرر کدهای جدید است و برای استفاده از آن به هیچ وجه نیازی به حصار کردن جنکینز، گیت لب و غیره نیست.
قبل از اینکه بفهمیم یک CI تمام عیار چگونه به نظر می رسد، اجازه دهید ابتدا در زمینه افرادی که آن را ارائه کرده اند غوطه ور شویم و دردی را که آنها سعی در حل آن داشتند احساس کنیم.
و درد کار گروهی را حل کردند!
بیایید به نمونه‌هایی از مشکلاتی که توسعه‌دهندگان هنگام توسعه در تیم‌ها با آن مواجه هستند، نگاه کنیم. در اینجا ما یک پروژه، یک شاخه اصلی در git و دو توسعه دهنده داریم.
و همانطور که همه مدتها به آن عادت کرده بودند، سر کار رفتند. ما یک کار در طرح بزرگ چیزها گرفتیم، یک شاخه ویژگی ایجاد کردیم و کد را نوشتیم.
یکی این ویژگی را سریعتر به پایان رساند و آن را در Master ادغام کرد.
دومی به زمان بیشتری نیاز داشت، بعداً ادغام شد و به درگیری ختم شد. حال، توسعه‌دهنده به‌جای نوشتن ویژگی‌های مورد نیاز کسب‌وکار، زمان و انرژی خود را صرف حل تعارض می‌کند.
هرچه ترکیب ویژگی خود با یک استاد معمولی دشوارتر باشد، زمان بیشتری را برای آن صرف می کنیم. و من این را با یک مثال نسبتاً ساده نشان دادم. این مثالی است که در آن فقط 2 توسعه دهنده وجود دارد. تصور کنید که 10 یا 15 یا 100 نفر در یک شرکت در یک مخزن بنویسند. برای حل همه این درگیری ها دیوانه خواهید شد.
یک مورد کمی متفاوت وجود دارد. ما یک استاد و چند توسعه دهنده داریم که کاری انجام می دهند.
آنها یک شاخه ایجاد کردند.
یکی مرد، همه چیز خوب بود، از تکلیف گذشت.
در همین حال توسعه دهنده دوم وظیفه خود را به عهده گرفت. فرض کنید برای بررسی فرستاده است. بسیاری از شرکت ها رویه ای به نام بررسی دارند. این عمل از یک طرف خوب و مفید است، از طرف دیگر از بسیاری جهات سرعت ما را کند می کند. ما وارد آن نمی‌شویم، اما در اینجا یک مثال عالی از آنچه که یک داستان مرور بد می‌تواند منجر شود، آورده شده است. شما یک درخواست کشش برای بررسی ارسال کرده اید. کار دیگری برای توسعه دهنده وجود ندارد. او شروع به چه کاری می کند؟ او شروع به انجام وظایف دیگر می کند.
در این مدت، توسعه دهنده دوم کار دیگری انجام داد.
نفر اول وظیفه سوم را تکمیل کرد.
و بعد از مدت ها بررسی او مورد آزمایش قرار گرفت و او سعی می کند کنار بیاید. چه خبر؟ تعداد زیادی از درگیری ها را می گیرد. چرا؟ زیرا در حالی که درخواست کشش او در بررسی وجود داشت، بسیاری از چیزها قبلاً در کد تغییر کرده بودند.
علاوه بر داستان با درگیری، داستانی با ارتباطات نیز وجود دارد. در حالی که موضوع شما در حال بررسی است، در حالی که منتظر چیزی است، در حالی که برای مدت طولانی روی یک ویژگی کار می کنید، دیگر مواردی که در پایگاه کد سرویس شما تغییر می کند را ردیابی نمی کنید. شاید چیزی که اکنون سعی در حل آن دارید قبلاً دیروز حل شده است و می توانید از روشی استفاده کنید و دوباره از آن استفاده کنید. اما شما این را نخواهید دید زیرا همیشه با یک شعبه قدیمی کار می کنید. و این شاخه منسوخ شده همیشه منجر به این می شود که مجبور شوید یک تضاد ادغام را حل کنید.
معلوم می شود که اگر به عنوان یک تیم کار کنیم، به عنوان مثال، یک نفر در مخزن هجوم نمی آورد، بلکه 5-10 نفر در مخزن هجوم می آورند، هر چه بیشتر کد خود را به استاد اضافه نکنیم، بیشتر رنج می بریم زیرا در نهایت به آن نیاز داریم. چیزی سپس آن را ادغام کنید. و هر چه تضادها بیشتر باشد و هر چه نسخه قدیمی تر با آن کار کنیم، مشکلات بیشتری داریم.
انجام کاری با هم دردناک است! ما همیشه سر راه همدیگر قرار می گیریم.
این مشکل بیش از 20 سال پیش مورد توجه قرار گرفت. من اولین اشاره به تمرین یکپارچه سازی مداوم در برنامه نویسی شدید را پیدا کردم.
Extreme Programming اولین فریم ورک چابک است. این صفحه در سال 96 ظاهر شد. و ایده این بود که از نوعی برنامه‌نویسی، برنامه‌ریزی و موارد دیگر استفاده کنیم تا توسعه تا حد امکان انعطاف‌پذیر باشد تا بتوانیم به سرعت به هرگونه تغییر یا نیاز مشتریان خود پاسخ دهیم. و آنها 24 سال پیش شروع به مواجهه با این موضوع کردند که اگر کاری را برای مدت طولانی و در حاشیه انجام دهید، زمان بیشتری را صرف آن می کنید زیرا درگیری دارید.
اکنون عبارت "ادغام مداوم" را به صورت جداگانه تجزیه و تحلیل خواهیم کرد. اگر مستقیماً آن را ترجمه کنیم، یکپارچگی مداوم دریافت می کنیم. اما اینکه چقدر پیوسته است، چندان مشخص نیست؛ بسیار ناپیوسته است. اما میزان یکپارچگی آن نیز چندان واضح نیست.
و به همین دلیل است که اکنون نقل قول هایی از Extreme Programming را به شما می دهم. و هر دو کلمه را جداگانه تحلیل خواهیم کرد.
یکپارچه سازی - همانطور که قبلاً گفتم، ما تلاش می کنیم تا اطمینان حاصل کنیم که هر مهندس با جدیدترین نسخه کد کار می کند، به طوری که تلاش می کند تا هرچه بیشتر کد خود را به یک شاخه مشترک اضافه کند، به طوری که اینها شاخه های کوچکی باشند. زیرا اگر بزرگ باشند، به راحتی می توانیم به مدت یک هفته درگیر تضادهای ادغام شویم. این امر به ویژه در صورتی صادق است که یک چرخه توسعه طولانی مانند آبشار داشته باشیم، جایی که توسعه‌دهنده به مدت یک ماه کنار رفت تا برخی از ویژگی‌های بزرگ را کاهش دهد. و او برای مدت طولانی در مرحله ادغام گیر خواهد کرد.
یکپارچه سازی زمانی است که ما شاخه خود را می گیریم و با استاد ادغام می کنیم، آن را ادغام می کنیم. هنگامی که ما یک توسعه دهنده transbase هستیم، یک گزینه نهایی وجود دارد، که در آن تلاش می کنیم اطمینان حاصل کنیم که فوراً بدون هیچ شاخه اضافی برای Master بنویسیم.
به طور کلی، یکپارچه سازی به معنای گرفتن کد شما و کشیدن آن به داخل Master است.
در اینجا منظور از کلمه "مستمر" چیست، چه چیزی استمرار نامیده می شود؟ تمرین نشان می دهد که توسعه دهنده تلاش می کند تا کد خود را در سریع ترین زمان ممکن یکپارچه کند. این هدف او هنگام انجام هر کار است - اینکه کد خود را در اسرع وقت به استاد تبدیل کند. در دنیای ایده آل، توسعه دهندگان این کار را هر چند ساعت یک بار انجام می دهند. یعنی شما یک مشکل کوچک را بردارید و آن را در Master ادغام کنید. همه چی عالیه. این چیزی است که شما برای آن تلاش می کنید. و این باید به طور مداوم انجام شود. به محض انجام کاری، بلافاصله آن را در اختیار استاد قرار می دهید.
و توسعه‌دهنده‌ای که چیزی را می‌سازد، مسئول کارهایی است که انجام داده تا کار کند و چیزی را خراب نکند. این جایی است که معمولاً داستان تست ظاهر می شود. ما می‌خواهیم آزمایش‌هایی را روی commit یا ادغام خود اجرا کنیم تا مطمئن شویم که کار می‌کند. و این جایی است که جنکینز می تواند به شما کمک کند.
اما با داستان ها: بیایید تغییرات را کوچک کنیم، اجازه دهید وظایف کوچک باشند، بیایید مشکلی ایجاد کنیم و بلافاصله سعی کنیم آن را به نحوی در استاد جاسازی کنیم - هیچ جنکینزی در اینجا کمکی نمی کند. زیرا جنکینز فقط به شما در اجرای تست ها کمک می کند.
شما می توانید بدون آنها انجام دهید. این به هیچ وجه به شما آسیب نمی رساند. زیرا هدف تمرین این است که تا حد امکان اندازه گیری شود تا زمان زیادی را برای هر گونه درگیری در آینده هدر ندهید.
بیایید تصور کنیم که به دلایلی در سال 2020 بدون اینترنت هستیم. و ما به صورت محلی کار می کنیم. ما جنکینز نداریم این خوبه. هنوز هم می توانید ادامه دهید و یک شعبه محلی ایجاد کنید. تو یه کد نوشتی ما کار را در 3-4 ساعت انجام دادیم. ما به مستر تغییر کردیم، یک git pull انجام دادیم و شاخه خود را در آنجا ادغام کردیم. آماده. اگر این کار را اغلب انجام می دهید، تبریک می گوییم، شما یکپارچه سازی مستمر دارید!
چه مدرکی در دنیای مدرن وجود دارد که ارزش صرف انرژی را دارد؟ چون به طور کلی سخت است. اگر سعی کنید اینگونه کار کنید، متوجه خواهید شد که اکنون برخی از برنامه ریزی ها تحت تأثیر قرار خواهد گرفت، باید زمان بیشتری را به تجزیه و تحلیل وظایف اختصاص دهید. زیرا اگر مرد ... را انجام دهید، آن وقت نمی توانید به سرعت کنار بیایید و بر همین اساس دچار مشکل خواهید شد. دیگر تمرین نخواهید داشت.
و گران تمام خواهد شد. از فردا با استفاده از Continuous Integration امکان کار فوری وجود نخواهد داشت. زمان زیادی طول می کشد تا همه شما به آن عادت کنید، زمان زیادی طول می کشد تا به کارهای تجزیه و تحلیل عادت کنید، زمان زیادی طول می کشد تا به انجام مجدد تمرین مرور عادت کنید، اگر دارید. . زیرا هدف ما این است که امروز ذوب شود. و اگر ظرف سه روز یک بررسی انجام دهید، مشکل دارید و Continuous Integration برای شما کار نمی کند.
اما آیا در حال حاضر شواهد مرتبطی داریم که به ما بگوید سرمایه گذاری در این عمل منطقی است؟
اولین چیزی که به ذهنم رسید State of DevOps بود. این مطالعه ای است که بچه ها به مدت 7 سال انجام داده اند. اکنون آنها این کار را به عنوان یک سازمان مستقل، اما تحت گوگل انجام می دهند.
و مطالعه آنها در سال 2018 همبستگی بین شرکت‌هایی را نشان داد که سعی می‌کنند از شاخه‌های کوتاه‌مدتی استفاده کنند که سریع ادغام می‌شوند، مکرراً ادغام می‌شوند و شاخص‌های عملکرد فناوری اطلاعات بهتری دارند.
این شاخص ها چیست؟ اینها 4 معیاری است که آنها از همه شرکت ها در پرسشنامه های خود می گیرند: فرکانس استقرار، زمان انجام تغییرات، زمان بازیابی خدمات، نرخ شکست تغییر.
و اولاً، این همبستگی وجود دارد، ما می دانیم که شرکت هایی که مرتباً اندازه گیری می کنند معیارهای بسیار بهتری دارند. و آنها شرکت‌ها را به چند دسته تقسیم می‌کنند: اینها شرکت‌های کندی هستند که چیزی آهسته تولید می‌کنند، با عملکرد متوسط، با عملکرد بالا و نخبگان. نخبگان نتفلیکس، آمازون هستند که فوق العاده سریع هستند، همه چیز را سریع، زیبا و کارآمد انجام می دهند.
داستان دوم که همین یک ماه پیش اتفاق افتاد. Technology Radar یک مقاله عالی در مورد Gitflow دارد. Gitflow از این نظر که شاخه های آن عمر طولانی دارند با بقیه متفاوت است. شاخه های آزاد هستند که برای مدت طولانی زندگی می کنند، و شاخه های دارای ویژگی هستند که برای مدت طولانی نیز زندگی می کنند. این تمرین در رادار فناوری به HOLD منتقل شده است. چرا؟ زیرا مردم با درد ادغام روبرو هستند.
اگر شاخه شما برای مدت طولانی زندگی کند، گیر می کند، پوسیده می شود و ما شروع به صرف زمان بیشتری برای ایجاد نوعی تغییر در آن می کنیم.
و اخیراً نویسنده Gitflow گفته است که اگر هدف شما Continuous Integration است، اگر هدف شما این است که می خواهید تا آنجا که ممکن است رول کنید، پس Gitflow ایده بدی است. او به طور جداگانه به مقاله اضافه کرد که اگر یک Backend دارید که می توانید برای این کار تلاش کنید، پس Gitflow برای شما اضافی است، زیرا Gitflow سرعت شما را کاهش می دهد، Gitflow با یکپارچه سازی برای شما مشکلاتی ایجاد می کند.
این بدان معنا نیست که Gitflow بد است و نباید استفاده شود. برای موارد دیگر است. به عنوان مثال، زمانی که نیاز به پشتیبانی از چندین نسخه از یک سرویس یا برنامه دارید، یعنی جایی که برای مدت طولانی به پشتیبانی نیاز دارید.
اما اگر با افرادی که از چنین خدماتی پشتیبانی می کنند صحبت کنید، دردسرهای زیادی خواهید شنید که این نسخه 3.2 بوده که 4 ماه پیش بود، اما این اصلاح در آن گنجانده نشده بود و اکنون برای ساخت آن، شما باید یک سری تغییرات ایجاد کنید. و حالا دوباره گیر کرده‌اند، و حالا یک هفته است که در تلاش برای پیاده‌سازی یک ویژگی جدید هستند.
همانطور که الکساندر کووالف به درستی در گفتگو اشاره کرد، همبستگی با علیت یکسان نیست. درست است. یعنی هیچ ارتباط مستقیمی وجود ندارد که اگر Continuous Integration داشته باشید، تمام معیارها عالی خواهند بود. اما یک همبستگی مثبت وجود دارد که اگر یکی یکی باشد، به احتمال زیاد دیگری نیز همینطور است. واقعیت نیست، اما به احتمال زیاد. این فقط یک همبستگی است.
به نظر می رسد که ما در حال انجام کاری هستیم، به نظر می رسد که ما در حال ادغام هستیم، اما چگونه می توانیم بفهمیم که ما هنوز یکپارچه سازی مداوم داریم، که اغلب در حال ادغام هستیم؟
Jez Humble نویسنده کتاب راهنما، شتاب، وب سایت تحویل مداوم و کتاب تحویل مداوم است. او این آزمایش را ارائه می دهد:
- کد مهندس هر روز به استاد می رسد.
- برای هر commitی که تست های واحد را اجرا می کنید.
- ساختمان در استاد سقوط کرد، در حدود 10 دقیقه درست شد.
او پیشنهاد می کند از آزمونی مانند این استفاده کنید تا مطمئن شوید که تمرین کافی دارید.
به نظر من دومی کمی بحث برانگیز است. یعنی اگه بتونی تو 10 دقیقه درستش کنی، Continuous Integration داری، به نظر من کمی عجیب به نظر میاد ولی منطقیه. چرا؟ زیرا اگر اغلب فریز می کنید به این معنی است که تغییرات شما کم است. اگر یک تغییر کوچک به این معنی است که ساخت اصلی شما خراب شده است، می توانید به سرعت یک نمونه را پیدا کنید زیرا تغییر کوچک است. در اینجا شما یک ادغام کوچک داشتید، 20-30 خط در آن تغییر کرد. و بر این اساس، می توانید به سرعت متوجه شوید که دلیل آن چیست، زیرا تغییرات کوچک هستند، شما یک منطقه بسیار کوچک برای جستجوی مشکل دارید.
و حتی اگر محصول ما پس از انتشار از بین برود، پس اگر تمرین یکپارچه سازی مداوم را داشته باشیم، عمل کردن برای ما بسیار آسان تر است، زیرا تغییرات کوچک هستند. بله، این روی برنامه ریزی تاثیر می گذارد. این آسیب خواهد زد. و احتمالاً سخت ترین کار در این تمرین عادت کردن به تقسیم کارها است، یعنی اینکه چگونه آن را انجام دهید تا بتوانید کاری را بردارید و در چند ساعت آن را انجام دهید و در همان زمان بررسی کنید، اگر شما یکی را دارید مرور درد جداست.
تست‌های واحد فقط یک دستیار است که به شما کمک می‌کند بفهمید که آیا ادغام شما موفقیت‌آمیز بوده است یا خیر. به نظر من، این نیز کاملاً اجباری نیست، زیرا این موضوع تمرین نیست.
این یک مقدمه کوتاه برای Continuous Integration است. این تمام چیزی است که در این عمل وجود دارد. من برای سوالات آماده هستم.
من فقط یک بار دیگر به اختصار خلاصه می کنم:
- Continuous Integration جنکینز نیست، Gitlab نیست.
- این یک ابزار نیست، این یک تمرین است که ما کد خود را تا آنجا که ممکن است در Master ادغام می کنیم.
- ما این کار را برای جلوگیری از درد عظیمی که با ادغام در آینده ایجاد می شود انجام می دهیم، یعنی اکنون کمی درد را تجربه می کنیم تا در آینده بیشتر تجربه نکنیم. تمام نکته همین است.
- در کنار، ارتباط از طریق کد وجود دارد، اما من به ندرت این را می بینم، اما این همان چیزی است که برای آن طراحی شده است.
پرسش
با کارهای تجزیه نشده چه کنیم؟
تجزیه شود. مشکل چیه؟ میشه مثال بزنید که تکلیف هست و تجزیه نشده؟
وظایفی وجود دارد که نمی توان آنها را از کلمه "به طور کامل" تجزیه کرد، به عنوان مثال، کارهایی که نیاز به تخصص بسیار عمیق دارند و در واقع می توان آنها را در طول یک ماه حل کرد تا به نتیجه قابل هضمی رسید.
اگر شما را به درستی درک کرده باشم، پس کار بزرگ و پیچیده ای وجود دارد که نتیجه آن فقط در یک ماه قابل مشاهده است؟
بله درست است. بله، ارزیابی نتیجه زودتر از یک ماه امکان پذیر خواهد بود.
خوب. به طور کلی این مشکلی نیست. چرا؟ زیرا در این مورد وقتی از شاخه ها صحبت می کنیم، از یک شاخه با ویژگی صحبت نمی کنیم. ویژگی ها می توانند بزرگ و پیچیده باشند. آنها می توانند بر تعداد زیادی از اجزا تأثیر بگذارند. و شاید نتوانیم آنها را به طور کامل در یک شاخه انجام دهیم. این خوبه. ما فقط باید این داستان را بشکنیم. اگر یک ویژگی کاملاً آماده نیست، این بدان معنا نیست که برخی از قطعات کد آن قابل ادغام نیستند. مثلاً مهاجرت را اضافه کردید و مراحلی در داخل ویژگی وجود دارد. فرض کنید یک مرحله دارید - یک مهاجرت انجام دهید، یک روش جدید اضافه کنید. و شما می توانید این موارد را هر روز اندازه گیری کنید.
خوب. آن وقت چه فایده ای دارد؟
کشتن هر روز چیزهای کوچک چه فایده ای دارد؟
بله.
اگر چیزی را بشکنند، بلافاصله آن را می بینید. شما یک قطعه کوچک دارید که چیزی را شکسته است، تعمیر آن برای شما آسان تر است. نکته این است که ادغام یک قطعه کوچک در حال حاضر بسیار ساده تر از ادغام یک قطعه بزرگ در چند هفته است. و نکته سوم اینکه مهندسان دیگر با نسخه فعلی کد کار خواهند کرد. آنها می بینند که برخی از مهاجرت ها در اینجا اضافه شده است و سپس روشی ظاهر می شود که ممکن است آنها نیز بخواهند از آن استفاده کنند. همه می بینند که در کد شما چه اتفاقی می افتد. برای این سه چیز است که تمرین انجام می شود.
ممنون، موضوع بسته شد!
(اولگ سوروکا) می توانم اضافه کنم؟ همه چیز را درست گفتید، فقط می خواهم یک عبارت اضافه کنم.
پس.
با Continuous Integration، کدها در یک شاخه مشترک ادغام می شوند، نه زمانی که ویژگی کاملاً آماده است، بلکه زمانی که ساخت از شکستن متوقف می شود. و شما می توانید با خیال راحت متعهد شوید که هر چند بار در روز به هر تعداد که می خواهید استاد شوید. جنبه دوم این است که اگر به دلایلی نمی توانید کار ماهانه را حداقل برای سه روز به وظایف تقسیم کنید، من حدود سه ساعت سکوت می کنم، پس شما یک مشکل بزرگ دارید. و این که شما Continuous Integration ندارید کمترین این مشکلات است. این به این معنی است که شما با معماری و روش های مهندسی صفر مشکل دارید. زیرا حتی اگر این تحقیق باشد، در هر صورت باید در قالب فرضیه یا چرخه تدوین شود.
ما در مورد 4 معیاری صحبت کردیم که شرکت های موفق را از شرکت های عقب مانده متمایز می کند. ما هنوز باید زندگی کنیم تا این 4 معیار را ببینیم. اگر به طور متوسط کار شما یک ماه طول می کشد تا تکمیل شود، ابتدا روی این معیار تمرکز می کنم. من اول آن را به 3 روز کاهش می دهم. و بعد از آن به Continuous فکر کردم.
آیا من به درستی متوجه شما شدم که فکر می کنید به طور کلی سرمایه گذاری در کارهای مهندسی اگر انجام هر کاری یک ماه طول بکشد، فایده ای ندارد؟
شما یکپارچگی مداوم دارید. و چنین موضوعی وجود دارد که در 10 دقیقه می توانید یک تعمیر را برطرف کنید یا آن را به عقب برگردانید. تصور کنید آن را بیرون آورده اید. علاوه بر این، شما حتی استقرار مداوم دارید، آن را برای تولید قرار دادید و تنها پس از آن متوجه شدید که مشکلی پیش آمده است. و باید آن را برگردانید، اما قبلاً پایگاه داده خود را منتقل کرده اید. شما قبلاً طرح پایگاه داده نسخه بعدی را دارید، علاوه بر این، نوعی نسخه پشتیبان نیز داشتید و داده ها نیز در آنجا نوشته شده بودند.
و چه جایگزینی دارید؟ اگر کد را برگردانید، دیگر نمی تواند با این پایگاه داده به روز شده کار کند.
پایه فقط به جلو حرکت می کند، بله.
افرادی که عملکردهای مهندسی ضعیفی دارند به احتمال زیاد کتاب قطور در مورد ... را نیز نخوانده اند. با پشتیبان چه کنیم؟ اگر از یک نسخه پشتیبان بازیابی کنید، به این معنی است که داده هایی را که در آن لحظه جمع آوری کرده اید از دست می دهید. به عنوان مثال، ما سه ساعت با نسخه جدید پایگاه داده کار کردیم، کاربران در آنجا ثبت نام کردند. شما از پشتیبان گیری قدیمی خودداری می کنید زیرا این طرح با نسخه جدید کار نمی کند، بنابراین این کاربران را از دست داده اید. و ناراضی هستند، فحش می دهند.
برای تسلط بر طیف کامل اقداماتی که از یکپارچگی مداوم و تحویل مداوم پشتیبانی می کنند، فقط یاد گرفتن نحوه نوشتن کافی نیست. اولاً، می تواند تعداد زیادی از آنها وجود داشته باشد، غیرعملی خواهد بود. بعلاوه تعداد زیادی روش دیگر مانند Scientific وجود دارد. چنین عملی وجود دارد، GitHub در یک زمان آن را محبوب کرد. این زمانی است که شما هم کد قدیمی و هم کد جدید را همزمان اجرا می کنید. این زمانی است که یک ویژگی ناتمام ایجاد می‌کنید، اما می‌تواند مقداری را برگرداند: یا به‌عنوان تابع یا Rest API. شما هم کد جدید و هم کد قدیمی را اجرا می کنید و تفاوت بین آنها را مقایسه می کنید. و اگر تفاوتی وجود دارد، این رویداد را ثبت می‌کنید. به این ترتیب می‌دانید که اگر برای مدت معینی بین این دو تناقض نداشتید، یک ویژگی جدید آماده دارید تا در بالای ویژگی قدیمی قرار دهید.
صدها روش از این دست وجود دارد. من پیشنهاد می کنم با توسعه transbase شروع کنید. او 100٪ روی یکپارچگی مداوم نیست، اما شیوه ها یکسان است، یکی بدون دیگری نمی تواند خوب زندگی کند.
آیا توسعه transbase را به عنوان مثالی ارائه کردید که در آن می‌توانید روش‌ها را ببینید یا به مردم پیشنهاد می‌کنید که از debelopment transbase استفاده کنند؟
نگاه کنید، زیرا آنها قادر به استفاده از آن نخواهند بود. برای استفاده از آنها باید زیاد مطالعه کنید. و وقتی شخصی می پرسد: "با یک ویژگی که یک ماه طول می کشد چه باید کرد، به این معنی است که او در مورد توسعه transbase مطالعه نکرده است." من هنوز آن را توصیه نمی کنم. من توصیه می کنم فقط بر روی این موضوع تمرکز کنید که چگونه به طور صحیح کارهای بزرگ را به کارهای کوچکتر تقسیم کنیم. این جوهر تجزیه است.
تجزیه یکی از ابزارهای معمار است. ابتدا تجزیه و تحلیل و سپس تجزیه و سپس سنتز و سپس ادغام انجام می دهیم. و اینگونه است که همه چیز برای ما درست می شود. و ما هنوز باید از طریق تجزیه به یکپارچگی مداوم رشد کنیم. در مرحله اول سوالاتی مطرح می شود، و ما در حال حاضر در مورد مرحله چهارم صحبت می کنیم، یعنی هر چه بیشتر ادغام را انجام دهیم، بهتر است. هنوز برای انجام این کار خیلی زود است؛ بهتر است ابتدا یکپارچگی خود را کاهش دهید.
شما باید تعدادی فلش و مربع روی نمودار بکشید. شما نمی توانید بگویید که اکنون نمودار معماری یک برنامه جدید را نشان می دهم و یک مربع را نشان می دهم که داخل آن یک دکمه سبز برای برنامه وجود دارد. در هر صورت مربع و فلش بیشتری وجود خواهد داشت. هر نموداری که دیدم بیش از یک نمودار داشت. و تجزیه، حتی در سطح نمایش گرافیکی، در حال حاضر در حال انجام است. بنابراین، مربع ها را می توان مستقل ساخت. اگر نه، پس من سوالات بزرگی از معمار دارم.
یک سوال از چت وجود دارد: "اگر بررسی اجباری است و زمان زیادی می برد، شاید یک روز یا بیشتر؟"
با تمرین مشکل دارید. بررسی نباید یک روز یا بیشتر طول بکشد. این همان داستان سوال قبلی است، فقط کمی ملایم تر. اگر بازبینی برای یک روز ادامه داشته باشد، به احتمال زیاد این بررسی در حال تغییر بسیار بزرگی است. این بدان معنی است که باید کوچکتر شود. در توسعه transbase، که اولگ توصیه کرد، داستانی به نام بررسی مداوم وجود دارد. ایده او این است که ما چنین درخواست کشش کوچکی را عمداً انجام می‌دهیم، زیرا تلاش می‌کنیم دائماً و در یک زمان ادغام شویم. و بنابراین درخواست کشش یک انتزاع یا 10 خط را تغییر می دهد. با تشکر از این بررسی، چند دقیقه طول می کشد.
اگر بررسی یک روز یا بیشتر طول بکشد، مشکلی وجود دارد. اولا، ممکن است مشکلاتی با معماری داشته باشید. یا این یک کد بزرگ است، مثلاً 1 خط. یا معماری شما آنقدر پیچیده است که انسان نمی تواند آن را درک کند. این یک مشکل کمی جانبی است، اما همچنین باید حل شود. شاید اصلا نیازی به بررسی نباشد. ما هم باید به این موضوع فکر کنیم. مرور چیزی است که شما را کند می کند. به طور کلی مزایای خود را دارد، اما باید بدانید که چرا این کار را انجام می دهید. آیا این راهی برای انتقال سریع اطلاعات برای شماست، آیا این روشی است برای تعیین استانداردهای داخلی یا چه؟ چرا شما به این نیاز دارید؟ زیرا بررسی باید یا خیلی سریع انجام شود یا به طور کلی لغو شود. این مانند توسعه transbase است - داستان بسیار زیبا است، اما فقط برای بچه های بالغ.
با توجه به 4 معیار، من همچنان توصیه می کنم آنها را حذف کنید تا متوجه شوید که این به چه چیزی منجر می شود. به اعداد نگاه کنید، به عکس نگاه کنید، چقدر همه چیز بد است.
(دیمیتری) من حاضرم در این مورد با شما وارد بحث شوم. اعداد و معیارها همه عالی هستند، تمرین ها عالی هستند. اما باید بدانید که آیا کسب و کار به آن نیاز دارد یا خیر. کسب و کارهایی وجود دارند که به چنین سرعتی در تغییر نیاز ندارند. من شرکت هایی را می شناسم که هر 15 دقیقه نمی توان آنها را تغییر داد. و نه به این دلیل که آنها خیلی بد هستند. این چنین چرخه زندگی است. و برای ایجاد ویژگی شاخه ها، ویژگی ضامن، به دانش عمیق نیاز دارید.
این پیچیده است. اگر می‌خواهید داستان مربوط به قابلیت جابجایی را با جزئیات بیشتری بخوانید، آن را به شدت توصیه می‌کنم . و یک مقاله فوق‌العاده توسط مارتین فاولر در مورد ویژگی‌های جابه‌جایی وجود دارد: انواع مختلفی که وجود دارد، چرخه‌های عمر و غیره. ویژگی تعویض پیچیده است.
و شما هنوز به این سوال پاسخ نداده اید: "آیا جنکینز مورد نیاز است یا نه؟"
جنکینز در هر صورت واقعا مورد نیاز نیست. با این حال، به طور جدی، ابزارها: جنکینز، گیتلب، راحتی را برای شما به ارمغان می آورد. خواهید دید که مونتاژ مونتاژ شده یا مونتاژ نشده است. آنها می توانند به شما کمک کنند، اما به شما تمرین نمی دهند. آنها فقط می توانند یک دایره به شما بدهند - Ok, Ok. و بعد، اگر شما هم تست بنویسید، چون اگر تستی وجود نداشته باشد، تقریبا بی معنی است. بنابراین، لازم است زیرا راحت تر است، اما به طور کلی می توانید بدون آن زندگی کنید، چیز زیادی از دست نخواهید داد.
یعنی اگر تمرین هایی دارید به این معنی است که به آن نیاز ندارید؟
درست است. من تست Jez Humble را توصیه می کنم. در آنجا من نگرش دوگانه ای نسبت به آخرین نکته دارم. اما به طور کلی، اگر سه چیز دارید، مدام ادغام می‌شوید، آزمایش‌هایی را روی commitها در Master اجرا می‌کنید، به سرعت بیلد را در Master تعمیر می‌کنید، پس شاید به هیچ چیز دیگری نیاز نداشته باشید.
در حالی که منتظر سوالات شرکت کنندگان هستیم، من یک سوال دارم. ما فقط در مورد کد محصول صحبت می کردیم. آیا از آن برای کد زیرساخت استفاده کرده اید؟ آیا این کد یکسان است، آیا اصول و چرخه زندگی یکسانی دارد یا چرخه های زندگی و اصول متفاوتی دارد؟ معمولاً وقتی همه از یکپارچگی و توسعه مستمر صحبت می کنند، همه فراموش می کنند که کد زیرساختی نیز وجود دارد. و اخیراً بیشتر و بیشتر شده است. و آیا همه این قوانین باید به آنجا آورده شود؟
حتی آنطور که باید باشد، عالی خواهد بود زیرا به همین ترتیب زندگی را آسان تر می کند. به محض اینکه با کد کار می کنیم، نه با اسکریپت های bash، اما کد معمولی داریم.
توقف، توقف، یک اسکریپت bash نیز کد است. به عشق قدیمی من دست نزن
باشه، خاطراتت را پایمال نمی کنم. من از bash بیزارم. همیشه زشت و ترسناک می شکند. و اغلب به طور غیرقابل پیش بینی خراب می شود، به همین دلیل است که آن را دوست ندارم. اما خوب، فرض کنید شما کد bash دارید. شاید من واقعاً نمی فهمم و چارچوب های آزمایشی معمولی وجود دارد. من فقط در جریان نیستم. و ما از همان مزایا برخورداریم.
به محض اینکه ما با زیرساخت به عنوان کد کار می کنیم، با مشکلات مشابه توسعه دهندگان مواجه می شویم. چند ماه پیش با شرایطی مواجه شدم که یکی از همکاران برای من درخواست کشش 1 خط در bash را ارسال کرد. و شما به مدت 000 ساعت در نقد شرکت می کنید. همین مشکلات پیش می آید. هنوز هم کد است. و هنوز هم یک همکاری است. ما با درخواست کشش گیر می‌کنیم و به این واقعیت گیر می‌دهیم که مثلاً در حال حل کردن تضادهای ادغام در همان bash هستیم.
من اکنون بسیار فعالانه به این موضوع در زیباترین برنامه نویسی زیرساخت نگاه می کنم. من اکنون پولومی را وارد زیرساخت کرده ام. این برنامه نویسی در خالص ترین شکل آن است. اینجا حتی زیباتر است، زیرا من تمام قابلیت های یک زبان برنامه نویسی را دارم، یعنی با همان if ها یک جابجایی زیبا از رنگ آبی درست کردم و همه چیز خوب است. یعنی تغییر من از قبل در استاد است. همه از قبل می توانند او را ببینند. مهندسان دیگر در مورد آن می دانند. قبلاً در آنجا تأثیر گذاشته است. با این حال، برای همه زیرساخت ها فعال نبود. مثلاً برای نیمکت‌های تست من روشن شد. بنابراین برای پاسخ مجدد به سوال شما ضروری است. به عنوان مهندسانی که با کد کار می کنند، زندگی را برای ما آسان تر می کند.
اگر کس دیگری سوالی دارد؟
من یک سوال دارم. من می خواهم بحث را با اولگ ادامه دهم. در کل فکر می کنم حق با شماست که اگر یک کار یک ماه طول بکشد با معماری مشکل دارید، در تجزیه و تحلیل، تجزیه، برنامه ریزی و ... مشکل دارید اما من این احساس را دارم که اگر شروع کنید سعی کنید مطابق با یکپارچگی مداوم زندگی کنید، سپس با برنامه ریزی شروع به اصلاح درد خواهید کرد، زیرا در هیچ جای دیگری از آن دور نخواهید شد.
(اولگ) بله، درست است. این عمل در تلاش با هر عمل جدی تغییر فرهنگ دیگری قابل مقایسه است. سخت ترین چیز برای غلبه بر عادات است، به خصوص عادت های بد. و اگر برای اجرای این عمل، تغییر جدی در عادات اطرافیان شما مورد نیاز است: توسعه دهندگان، مدیریت، مدیر تولید، پس شگفتی ها در انتظار شما هستند.
چه شگفتی هایی می تواند وجود داشته باشد؟ فرض کنید تصمیم گرفتید که بیشتر اوقات ادغام شوید. و شما چیزهای دیگری دارید که به یکپارچه سازی مرتبط هستند، به عنوان مثال، مصنوعات. و در شرکت شما، برای مثال، این سیاست وجود دارد که هر مصنوع باید به نحوی در نوعی سیستم ذخیره سازی مصنوعات حساب شود. و کمی زمان می برد. یک شخص باید کادری را که به عنوان مدیر انتشار، این مصنوع را آزمایش کرده است، علامت بزند تا مطمئن شود که برای عرضه در تولید آماده است. اگر 5-10-15 دقیقه طول می کشد، اما شما هفته ای یک بار طرح بندی را انجام می دهید، پس از آن صرف نیم ساعت یک بار در هفته مالیات کمی است.
اگر یکپارچه سازی پیوسته را 10 بار در روز انجام دهید، 10 بار باید در 30 دقیقه ضرب شود. و این بیش از مقدار زمان کار این مدیر انتشار است. او فقط از انجام آن خسته می شود. برای برخی از روش ها هزینه های ثابتی وجود دارد. همین.
و شما باید یا این قانون را لغو کنید تا دیگر چنین زباله هایی را انجام ندهید، یعنی به صورت دستی مدرکی را برای مطابقت با چیزی اختصاص ندهید. شما کاملاً به مجموعه ای خودکار از تست های آمادگی متکی هستید.
و اگر از کسی مدرکی نیاز دارید تا رئیس آن را امضا کند و بدون اینکه واسیا بگوید اجازه می دهد و غیره وارد تولید نمی شوید - همه این مزخرفات سر راه تمرین کننده قرار می گیرد. زیرا اگر برخی از فعالیت های مرتبط با مالیات وجود داشته باشد، همه چیز 100 برابر افزایش می یابد. بنابراین، تغییر اغلب با شادی مورد استقبال همه قرار نمی گیرد. زیرا عادات افراد به سختی تغییر می کند.
وقتی فردی کار معمول خود را انجام می دهد، تقریباً بدون فکر آن را انجام می دهد. بار شناختی او صفر است. او فقط با آن بازی می کند، او قبلاً یک چک لیست در سر دارد، او آن را هزار بار انجام داده است. و به محض اینکه آمدید و به او بگویید: "بیایید این تمرین را لغو کنیم و از دوشنبه تمرین جدیدی را معرفی کنیم"، برای او یک بار شناختی قدرتمند می شود. و به یکباره به سراغ همه می آید.
بنابراین، ساده ترین چیز، اگرچه همه نمی توانند این تجمل را بپردازند، اما این کاری است که من همیشه انجام می دهم، این زیر است. اگر یک پروژه جدید شروع شود، معمولاً تمام اقدامات آزمایش نشده بلافاصله در این پروژه جمع می شوند. در حالی که پروژه جوان است، ما واقعاً هیچ چیز را به خطر نمی اندازیم. هنوز هیچ Prod وجود ندارد، چیزی برای تخریب وجود ندارد. بنابراین می توان از آن به عنوان آموزش استفاده کرد. این رویکرد کار می کند. اما همه شرکت ها این فرصت را ندارند که چنین پروژه هایی را اغلب شروع کنند. اگرچه این نیز کمی عجیب است، زیرا در حال حاضر یک تحول دیجیتالی کامل وجود دارد، همه باید آزمایش هایی را انجام دهند تا از رقبا عقب نمانند.
در اینجا به این نتیجه می رسید که ابتدا باید درک درستی از آنچه باید انجام دهید داشته باشید. دنیا ایده آل نیست و پرود هم ایده آل نیست.
بله، این چیزها به هم مرتبط هستند.
کسب‌وکارها همچنین همیشه نمی‌دانند که باید این راه را طی کنند.
شرایطی وجود دارد که هیچ تغییری در آن امکان پذیر نیست. این شرایطی است که فشار روی تیم بیشتر است. تیم در حال حاضر کاملاً سوخته است. او وقت خالی برای هیچ آزمایشی ندارد. آنها از صبح تا عصر روی ویژگی ها کار می کنند. و مدیریت امکانات کمتر و کمتری دارد. بیشتر و بیشتر مورد نیاز است. در چنین شرایطی به هیچ وجه امکان تغییر وجود ندارد. فقط می توان به تیم گفت که فردا مانند دیروز انجام خواهیم داد، فقط باید کمی ویژگی های بیشتری ایجاد کنیم. از این نظر، هیچ انتقالی به هیچ عملی امکان پذیر نیست. این یک وضعیت کلاسیک است که زمانی برای تیز کردن تبر وجود ندارد، درختان باید قطع شوند، بنابراین آنها آن را با یک تبر کسل کننده قطع می کنند. در اینجا هیچ نکته ساده ای وجود ندارد.
(دیمیتری) توضیحی را از چت خواهم خواند: «اما ما به پوشش آزمایشی زیادی در سطوح مختلف نیاز داریم. چقدر زمان برای آزمون ها اختصاص داده شده است؟ کمی گران است و زمان زیادی می برد.»
(اولگ) این یک تصور غلط کلاسیک است. باید تست های کافی برای اطمینان شما وجود داشته باشد. یکپارچه سازی مداوم چیزی نیست که در آن 100٪ تست ها ابتدا انجام شود و تنها پس از آن شروع به استفاده از این عمل کنید. Continuous Integration بار شناختی شما را کاهش می دهد به این دلیل که هر یک از تغییراتی که با چشمان خود می بینید آنقدر واضح است که می دانید حتی بدون آزمایش چیزی را می شکند یا خیر. شما می توانید به سرعت این را در ذهن خود آزمایش کنید زیرا تغییرات کوچک هستند. حتی اگر فقط تسترهای دستی داشته باشید، برای آنها نیز راحت تر است. بیرون آمدی و گفتی: "ببین، چیزی شکسته است؟" آنها بررسی کردند و گفتند: "نه، چیزی خراب نشده است." زیرا آزمایش کننده می داند کجا باید نگاه کند. شما یک commit مرتبط با یک قطعه کد دارید. و این با رفتار خاصی مورد سوء استفاده قرار می گیرد.
در اینجا شما، البته، زینت بخشید.
(دیمیتری) من در اینجا موافق نیستم. یک تمرین وجود دارد - توسعه آزمایش محور، که شما را از این امر نجات می دهد.
(اولگ) خوب، من هنوز به آن نقطه نرسیده ام. اولین توهم این است که شما باید 100% تست ها را بنویسید یا اصلا نیازی به انجام Continuous Integration ندارید. این درست نیست. این دو عمل موازی هستند. و مستقیماً وابسته نیستند. پوشش تست شما باید بهینه باشد. بهینه - این بدان معنی است که شما خودتان مطمئن هستید که کیفیت استادی که استاد شما پس از انجام تعهد در آن باقی مانده است به شما امکان می دهد با اطمینان دکمه "Deploy" را در یک عصر جمعه مست کنید. چطور به این میرسی؟ از طریق بررسی، از طریق پوشش، از طریق نظارت خوب.
نظارت خوب از آزمایش ها قابل تشخیص نیست. اگر یک بار تست ها را روی pre prod اجرا کنید، آنگاه تمام اسکریپت های کاربری شما را یک بار بررسی می کنند و تمام. و اگر آنها را در یک حلقه بی پایان اجرا کنید، پس این سیستم نظارت مستقر شما است که بی‌پایان همه چیز را آزمایش می‌کند - چه خراب شود یا نه. در این حالت تنها تفاوت این است که یک یا دو بار انجام شود. مجموعه بسیار خوبی از تست ها... در حال اجرا بی پایان، این نظارت است. و نظارت صحیح باید اینگونه باشد.
و بنابراین، اینکه دقیقاً چگونه وقتی عصر جمعه آماده می شوید و به خانه می روید، به این حالت خواهید رسید، یک سؤال دیگر است. شاید شما فقط یک ابله جسور باشید.
بیایید کمی به Continuous Integration برگردیم. ما به یک تمرین پیچیده کمی متفاوت فرار کردیم.
و توهم دوم این است که آنها می گویند که MVP باید سریع انجام شود، بنابراین آزمایش در آنجا اصلاً لازم نیست. مطمئناً به این شکل نیست. واقعیت این است که وقتی یک داستان کاربری را در یک MVP می نویسید، یا می توانید آن را روی توپ توسعه دهید، یعنی شنیدید که نوعی داستان کاربری وجود دارد و بلافاصله برای کدنویسی آن دویدید یا می توانید با استفاده از TDD کار کنید. و طبق TDD، همانطور که تمرین نشان می دهد، بیشتر طول نمی کشد، یعنی آزمایش ها یک عارضه جانبی هستند. تمرین TDD در مورد آزمایش نیست. علیرغم آنچه که Test Driven Development نامیده می شود، اصلاً در مورد آزمایش نیست. این نیز یک رویکرد معماری است. این رویکردی است برای نوشتن دقیقاً آنچه لازم است و ننوشتن آنچه لازم نیست. این تمرین تمرکز بر تکرار بعدی تفکر شما از نظر ایجاد معماری اپلیکیشن است.
بنابراین خلاصی از این توهمات چندان آسان نیست. MVP و تست ها با هم تناقضی ندارند. حتی، برعکس، اگر MVP را با استفاده از تمرین TDD انجام دهید، آن را بهتر و سریعتر از انجام آن بدون تمرین، اما روی توپ انجام خواهید داد.
این یک ایده بسیار غیر بدیهی و پیچیده است. وقتی می شنوید که اکنون تست های بیشتری خواهم نوشت و در عین حال کاری را سریعتر انجام خواهم داد، کاملاً ناکافی به نظر می رسد.
(دیمیتری) بسیاری از مردم اینجا، وقتی به MVP زنگ می زنند، مردم آنقدر تنبل هستند که چیزی عادی بنویسند. و اینها هنوز چیزهای متفاوتی هستند. نیازی نیست که MVP را به چیز بدی تبدیل کنید که کار نمی کند.
بله، بله، حق با شماست.
و سپس به طور ناگهانی MVP در تولید.
برای همیشه
و TDD وقتی می شنوید که تست می نویسید و به نظر می رسد کار بیشتری انجام می دهید بسیار غیرعادی به نظر می رسد. خیلی عجیب به نظر می رسد، اما در واقع به این ترتیب سریعتر و زیباتر به نظر می رسد. وقتی تستی را می نویسید، از قبل در ذهن خود بسیار فکر می کنید که چه کدی و چگونه نامیده می شود و همچنین چه رفتاری از آن انتظار داریم. شما فقط نمی گویید من فلان تابع را نوشتم و کاری انجام می دهد. اولش فکر می کردی فلان شرایط داره، فلان و فلان صداش میشه. شما این موضوع را با تست‌ها پوشش می‌دهید و از این طریق متوجه می‌شوید که رابط‌های شما در داخل کد شما چگونه به نظر می‌رسند. این تاثیر زیادی بر معماری دارد. کد شما به طور خودکار ماژولارتر می شود، زیرا ابتدا سعی می کنید بفهمید که چگونه آن را آزمایش خواهید کرد و تنها سپس آن را بنویسید.
اتفاقی که با TDD برای من افتاد این بود که در مقطعی زمانی که هنوز برنامه نویس Ruby بودم، یک مربی روبی استخدام کردم. و او می گوید: "بیایید آن را طبق TDD انجام دهیم." فکر کردم: "لعنتی، حالا باید چیز دیگری بنویسم." و ما توافق کردیم که ظرف دو هفته تمام کدهای کاری را با استفاده از TDD در پایتون بنویسم. بعد از دو هفته، متوجه شدم که نمی‌خواهم برگردم. بعد از دو هفته تلاش برای به کار بردن این در همه جا، متوجه می شوید که حتی فکر کردن برای شما چقدر آسان تر شده است. اما این واضح نیست، بنابراین به همه توصیه می کنم که اگر احساس می کنید که TDD دشوار، وقت گیر و غیر ضروری است، سعی کنید فقط دو هفته به آن پایبند باشید. دو تا برایم کافی بود.
(دیمیتری) ما می توانیم این ایده را از نقطه نظر عملیات زیرساخت گسترش دهیم. قبل از اینکه هر چیز جدیدی را راه اندازی کنیم، نظارت انجام می دهیم و سپس راه اندازی می کنیم. در این صورت نظارت برای ما یک آزمایش عادی می شود. و توسعه از طریق نظارت وجود دارد. اما تقریباً همه می گویند که طولانی است ، من تنبل هستم ، یک پیش نویس موقت تهیه کردم. اگر ما نظارت معمولی انجام داده باشیم، وضعیت سیستم CI را درک می کنیم. و سیستم CI نظارت زیادی دارد. ما وضعیت سیستم را درک می کنیم، می فهمیم که چه چیزی در داخل آن است. و در حین توسعه فقط سیستم را طوری می سازیم که به حالت مطلوب برسد.
این شیوه ها برای مدت طولانی شناخته شده است. ما حدود 4 سال پیش در این مورد بحث کردیم. اما در 4 سال عملا هیچ چیز تغییر نکرده است.
اما در این یادداشت، پیشنهاد می‌کنم که بحث رسمی پایان یابد.
ویدیو (به عنوان یک عنصر رسانه درج شده است، اما به دلایلی کار نمی کند):
منبع: www.habr.com