این گزارش در مورد برخی از شیوه های DevOps صحبت خواهد کرد، اما از دیدگاه یک توسعه دهنده. به طور معمول، همه مهندسانی که به DevOps می پیوندند قبلاً چندین سال تجربه مدیریتی دارند. اما این بدان معنا نیست که در اینجا جایی برای توسعه دهنده وجود ندارد. اغلب اوقات، توسعه‌دهندگان مشغول رفع «اشکال بسیار مهم بعدی در روز» هستند و وقت ندارند حتی یک نگاه سریع به قسمت DevOps بیندازند. در درک نویسنده، DevOps، اولاً، عقل سلیم است. ثانیاً، فرصتی است برای تأثیرگذاری بیشتر. اگر یک توسعه دهنده هستید، عقل سلیم دارید و می خواهید به عنوان یک بازیکن تیم موثرتر باشید، این گزارش برای شماست.
بگذارید خودم را معرفی کنم، کاملاً اعتراف می کنم که افرادی در اتاق هستند که من را نمی شناسند. نام من Anton Boyko است، من MVP Microsoft Azure هستم. MVP چیست؟ این Model-View-Presenter است. Model-View-Presenter دقیقا من هستم.
علاوه بر این، من در حال حاضر سمت معمار راه حل را در Ciklum دارم. و اخیراً برای خودم چنین دامنه زیبایی خریدم و ایمیلم را که معمولاً در ارائه ها نشان می دهم به روز کردم. می توانید برای من در آدرس زیر بنویسید: me [dog] byokoant.pro. می توانید سوالات خود را به من ایمیل کنید. من معمولا به آنها پاسخ می دهم. تنها چیزی که وجود دارد این است که من نمی خواهم سؤالاتی را از طریق ایمیل دریافت کنم که مربوط به دو موضوع است: سیاست و مذهب. شما می توانید در مورد هر چیز دیگری از طریق ایمیل برای من بنویسید. مدتی می گذرد، جواب می دهم.
چند کلمه در مورد خودم:
- الان 10 سال است که در این زمینه هستم.
- من در مایکروسافت کار می کردم.
- من پدر بنیانگذار جامعه لاجوردی اوکراینی هستم که در جایی در سال 2014 تأسیس کردیم. و ما هنوز آن را داریم و در حال توسعه آن هستیم.
- من همچنین پدر بنیانگذار کنفرانس لاجوردی هستم که در اوکراین میزبان آن هستیم.
- من همچنین به سازماندهی Bootcamp جهانی Azure در کیف کمک می کنم.
- همانطور که گفتم، من MVP Microsoft Azure هستم.
- من اغلب در کنفرانس ها صحبت می کنم. من واقعا عاشق سخنرانی در کنفرانس هستم. در طول یک سال گذشته توانستم حدود 40 بار اجرا داشته باشم. اگر از اوکراین، بلاروس، لهستان، بلغارستان، سوئد، دانمارک، هلند، اسپانیا عبور کنید یا کشور دیگری را در اروپا بدهید یا بگیرید، این امکان وجود دارد که وقتی به کنفرانسی بروید که موضوع ابری در جریان آن وجود دارد، ممکن است من را در لیست سخنرانان ببینید.
- من هم از طرفداران Star Trek هستم.
بیایید کمی در مورد دستور کار صحبت کنیم. دستور کار ما بسیار ساده است:
- ما در مورد اینکه DevOps چیست صحبت خواهیم کرد. بیایید صحبت کنیم که چرا این مهم است. قبلاً DevOps یک کلمه کلیدی بود که در رزومه خود می نوشتید و بلافاصله + 500 دلار حقوق دریافت می کردید. حالا باید مثلاً بلاک چین را در رزومه خود بنویسید تا +500 دلار به حقوق خود برسید.
- و سپس، هنگامی که کمی در مورد این موضوع فهمیدیم، در مورد اینکه اقدامات DevOps چیست صحبت خواهیم کرد. اما نه در زمینه DevOps به طور کلی، بلکه در مورد آن دسته از اقدامات DevOps که ممکن است برای توسعه دهندگان جالب باشد. من به شما می گویم که چرا آنها ممکن است برای شما جالب باشند. من به شما می گویم که چرا اصلاً باید این کار را انجام دهید و چگونه می تواند به شما کمک کند درد کمتری را تجربه کنید.
تصویری سنتی که خیلی ها نشان می دهند. این چیزی است که در بسیاری از پروژه ها اتفاق می افتد. این زمانی است که ما بخش های توسعه و عملیات داریم که از نرم افزار ما پشتیبانی می کنند. و این بخش ها با هم ارتباطی ندارند.
شاید، اگر نمی‌توانید آن را به وضوح در بخش‌های DevOps و عملیات حس کنید، می‌توانید با بخش‌های Dev و QA تشبیه کنید. افرادی هستند که نرم افزار توسعه می دهند و افراد QA هستند که از نظر توسعه دهندگان بد هستند. به عنوان مثال، من کد فوق العاده خود را به مخزن می نویسم و یک نفر شرور آنجا نشسته است که این کد را به من برمی گرداند و می گوید کد شما بد است.
این همه به این دلیل اتفاق می افتد که مردم با یکدیگر ارتباط برقرار نمی کنند. و آنها برخی بسته ها، برخی کاربردها را از طریق دیوار سوء تفاهم به یکدیگر می اندازند و سعی می کنند با آنها کاری انجام دهند.
فرهنگ DevOps دقیقاً برای تخریب این دیوار طراحی شده است. افراد را مجبور کنید با یکدیگر ارتباط برقرار کنند و حداقل بفهمند افراد مختلف در پروژه چه کاری انجام می دهند و چرا کار آنها مهم است.
و وقتی در مورد DevOps صحبت می کنیم، کسی به شما می گوید که DevOps زمانی است که پروژه یکپارچه سازی مداوم داشته باشد. کسی خواهد گفت که DevOps در صورتی است که پروژه عمل "زیرساخت به عنوان کد" را اجرا کند. کسی خواهد گفت که اولین گام برای DevOps شاخه‌بندی ویژگی، پرچم‌های ویژگی است.
اساساً، همه اینها در نوع خود صادق است. اما اینها تنها شیوه های نهایی ما هستند. قبل از رفتن به این شیوه ها، پیشنهاد می کنم به این اسلاید نگاه کنید که 3 مرحله پیاده سازی متدولوژی Dev-Ops را در پروژه شما، در شرکت شما نشان می دهد.
این اسلاید یک نام غیر رسمی دوم نیز دارد. می توانید به صورت آنلاین جستجو کنید تا بدانید 3 تفنگدار DevOps چیست. این امکان وجود دارد که شما این مقاله را پیدا کنید. چرا 3 تفنگدار؟ در زیر می گوید: افراد، فرآیندها و محصولات، i.e. PPP - پورتوس، پورتوس و پورتوس. در اینجا 3 تفنگدار DevOps هستند. این مقاله با جزئیات بیشتری توضیح می دهد که چرا این مهم است و چه چیزی مستلزم آن است.
هنگامی که شروع به پیاده سازی فرهنگ DevOps می کنید، بسیار مهم است که به ترتیب زیر پیاده سازی شود.
در ابتدا باید با مردم صحبت کنید. و باید به مردم توضیح دهید که چیست و چگونه می توانند از مزایای آن بهره مند شوند.
کنفرانس ما DotNet Fest نام دارد. و همانطور که برگزارکنندگان به من گفتند، ما عمدتاً مخاطبان توسعه دهندگان را به اینجا دعوت کردیم، بنابراین امیدوارم اکثر افراد حاضر در سالن در توسعه مشارکت داشته باشند.
ما در مورد افراد صحبت خواهیم کرد، ما در مورد آنچه که توسعه دهندگان می خواهند هر روز انجام دهند صحبت خواهیم کرد. آنها بیشتر از همه چه می خواهند؟ آنها می خواهند چند کد جدید بنویسند، از چارچوب های جدید استفاده کنند، ویژگی های جدیدی ایجاد کنند. توسعه دهندگان حداقل چه چیزی می خواهند؟ رفع اشکالات قدیمی امیدوارم با من موافق باشید. این چیزی است که توسعه دهندگان می خواهند. آنها می خواهند ویژگی های جدید بنویسند، آنها نمی خواهند اشکالات را برطرف کنند.
تعداد باگ‌هایی که یک توسعه‌دهنده خاص تولید می‌کند به این بستگی دارد که بازوهای او چقدر صاف هستند و چقدر از روی شانه‌هایش رشد میکنند و نه از جیب باسن. اما با این وجود، زمانی که یک پروژه بزرگ داریم، گاهی اوقات پیش می‌آید که پیگیری همه چیز غیرممکن است، بنابراین خوب است که از روش‌هایی استفاده کنیم که به ما کمک می‌کند کدهای پایدارتر و با کیفیت‌تری بنویسیم.
QAها بیشتر از همه چه می خواهند؟ نمی دانم در سالن هستند یا نه. برای من سخت است که بگویم من یک QA می خواهم، زیرا هرگز چنین نبوده ام. و بدون توهین به بچه ها، گفته می شود که امیدوارم هرگز نخواهم کرد. اما نه به این دلیل که کار آنها را بی معنی و بیهوده می دانم، بلکه به این دلیل که خود را فردی نمی دانم که بتواند این کار را به نحو احسن انجام دهد، بنابراین حتی برای انجام آن تلاش نمی کنم. اما از آنجایی که من می‌دانم، چیزی که QA بیشتر از همه دوست ندارد این است که صبح کار کند، دائماً نوعی آزمایش رگرسیون را اجرا کند، روی همان اشکالاتی که 3 اسپرینت قبل به توسعه‌دهندگان گزارش کرده‌اند، قدم بگذارد و بگوید: «کی می‌خواهی ، مسیو د "آرتگنان، این اشکال را برطرف کنید." و موسیو دآرتانیان به او پاسخ می دهد: "بله، بله، بله، من قبلاً آن را درست کرده ام." و چگونه اتفاق می افتد که من یک باگ را رفع کردم و در طول مسیر 5 تا درست کردم.
افرادی که از این راه حل در تولید پشتیبانی می کنند می خواهند این راه حل بدون اشکال کار کند، به طوری که مجبور نباشند هر جمعه، زمانی که همه افراد عادی به نوار می روند، سرور را راه اندازی مجدد کنند. توسعه دهندگان در روز جمعه مستقر شدند، مدیران تا شنبه می نشینند و سعی می کنند این استقرار را بالا ببرند و رفع کنند.
و هنگامی که به مردم توضیح می دهید که هدف آنها حل مشکلات مشابه است، می توانید به سمت رسمی کردن فرآیندها بروید. این خیلی مهمه. چرا؟ زیرا زمانی که می گوییم "رسمی سازی"، برای شما مهم است که نحوه انجام فرآیندهای شما حداقل در جایی روی دستمال سفره را شرح دهید. شما باید بدانید که اگر مثلاً در یک محیط QA یا یک محیط تولید مستقر شوید، همیشه به این ترتیب اتفاق می‌افتد؛ در این مراحل، برای مثال، تست‌های واحد خودکار و تست‌های UI را اجرا می‌کنیم. پس از استقرار، بررسی می کنیم که آیا استقرار خوب بوده است یا ضعیف. اما شما در حال حاضر یک لیست واضح از اقداماتی دارید که باید بارها و بارها در هنگام استقرار در تولید تکرار شوند.
و تنها زمانی که فرآیندهای شما رسمی شد، شروع به انتخاب محصولاتی می‌کنید که به شما در خودکارسازی این فرآیندها کمک میکنند.
متأسفانه، من اغلب می بینم که این اتفاق برعکس می افتد. به محض شنیدن کلمه DevOps، بلافاصله پیشنهاد نصب Jenkins را می دهد، زیرا معتقدند به محض نصب Jenkins، DevOps خواهند داشت. آنها جنکینز را نصب کردند، مقاله‌های «چگونه» را در وب‌سایت جنکینز مطالعه کردند، سعی کردند فرآیندها را در این مقاله‌های «چگونه» قرار دهند، و سپس به سراغ مردم آمدند و مردم را خم کردند و گفتند که کتاب می‌گوید که باید این کار را به این صورت انجام دهید، بنابراین ما این کار را به این طریق انجام می دهیم.
اینطور نیست که جنکینز ابزار بدی باشد. به هیچ وجه قصد ندارم این را بگویم. اما این فقط یکی از محصولات است. و اینکه کدام محصول استفاده می کنید باید آخرین تصمیم شما باشد و به هیچ وجه اولین تصمیم شما نیست. محصول شما نباید با اجرای فرهنگ و رویکردها هدایت شود. درک این موضوع بسیار مهم است، به همین دلیل است که من زمان زیادی را صرف این اسلاید می کنم و همه اینها را برای مدت طولانی توضیح می دهم.
بیایید در مورد شیوه های DevOps به طور کلی صحبت کنیم. آنها چه هستند؟ تفاوت در چیست؟ چگونه آنها را امتحان کنیم؟ چرا آنها مهم هستند؟
اولین تمرینی که ممکن است در مورد آن شنیده باشید، یکپارچگی مداوم نام دارد. شاید فردی در پروژه دارای یکپارچگی مداوم (CI) باشد.
بزرگترین مشکل این است که اغلب وقتی از شخصی می پرسم: "آیا شما در پروژه CI دارید؟" و او می‌گوید: «بله»، سپس وقتی می‌پرسم او چه کار می‌کند، کاملاً تمام فرآیند اتوماسیون را برای من توصیف می‌کند. این کاملا درست نیست.
در واقع، تمرین CI فقط با هدف ادغام کدهایی است که افراد مختلف در نوعی پایه کد واحد می نویسند. همین.
در کنار CI، معمولاً اقدامات دیگری نیز در این راه وجود دارد - مانند استقرار مداوم، مدیریت انتشار، اما بعداً در مورد آن صحبت خواهیم کرد.
خود CI به ما می گوید که افراد مختلف کد می نویسند و این کد باید به طور مداوم در یک پایه کد واحد ادغام شود.
این چه چیزی به ما می دهد و چرا مهم است؟ اگر DotNet داشته باشیم، خوب است، این یک زبان کامپایل شده است، ما می توانیم برنامه خود را کامپایل کنیم. اگر کامپایل شود، پس این نشانه خوبی است. این هنوز هیچ معنایی ندارد، اما اولین نشانه خوبی است که حداقل می توانیم جمع آوری کنیم.
سپس می توانیم چند تست را اجرا کنیم که این نیز یک تمرین جداگانه است. تست ها همه سبز هستند - این دومین علامت خوب است. اما باز هم، این هیچ معنایی ندارد.
اما چرا این کار را می کنید؟ تمام اعمالی که امروز در مورد آنها صحبت خواهم کرد تقریباً دارای ارزش مشابهی هستند، یعنی تقریباً همان فواید و همچنین تقریباً به همان روش اندازه گیری می شوند.
اول، به شما امکان می دهد سرعت تحویل را افزایش دهید. چگونه این به شما امکان می دهد تا تحویل را تسریع کنید؟ وقتی تغییرات جدیدی در پایه کد خود ایجاد می کنیم، بلافاصله می توانیم کاری را با این کد انجام دهیم. ما منتظر نمی‌مانیم تا پنجشنبه بیاید، زیرا روز پنجشنبه آن را به QA Environment عرضه می‌کنیم، این کار را همین‌جا و همین‌جا انجام می‌دهیم.
من یک داستان غم انگیز از زندگی خود را برای شما تعریف می کنم. خیلی وقت پیش بود، وقتی هنوز جوان و خوش تیپ بودم. اکنون من جوان، زیبا و باهوش و متواضع هستم. چند وقت پیش در یک پروژه بودم. ما یک تیم بزرگ از حدود 30 توسعه دهنده داشتیم. و ما یک پروژه بزرگ و بزرگ Enterprise داشتیم که برای حدود 10 سال توسعه یافت. و شعبه های مختلفی داشتیم. در مخزن شعبه ای داشتیم که توسعه دهندگان در آن قدم می زدند. و یک شعبه بود که نسخه کد در حال تولید را نمایش می داد.
شعبه تولید 3 ماه از شعبه ای که در اختیار توسعه دهندگان بود عقب بود. این یعنی چی؟ این به این معنی است که به محض اینکه من در جایی باگی دارم که به دلیل تقصیر توسعه دهندگان به تولید می رود، زیرا آنها آن را اجازه داده اند، و به دلیل تقصیر QA، زیرا آنها به آن نگاه کرده اند، به این معنی است که اگر من یک task for hotfix برای تولید، سپس باید تغییرات کدم را 3 ماه پیش برگردانم. باید آنچه را که 3 ماه پیش داشتم به خاطر بیاورم و سعی کنم آن را درست کنم.
اگر هنوز این تجربه را نداشته اید، می توانید آن را در پروژه خانه خود امتحان کنید. نکته اصلی این است که آن را در مورد تجاری امتحان نکنید. چند خط کد بنویسید، آنها را به مدت شش ماه فراموش کنید، و سپس برگردید و سعی کنید به سرعت توضیح دهید که این خطوط کد در مورد چیست و چگونه می توانید آنها را اصلاح یا بهینه کنید. این یک تجربه بسیار بسیار هیجان انگیز است.
اگر ما یک تمرین یکپارچه سازی مداوم داشته باشیم، این به ما امکان می دهد تا به محض اینکه کدم را نوشتم، آن را با تعدادی ابزار خودکار در اینجا و همین حالا بررسی کنیم. این ممکن است تصویر کاملی را به من ارائه ندهد، اما با این وجود، حداقل برخی از خطرات را از بین می برد. و اگر اشکال احتمالی وجود داشته باشد، من در حال حاضر در مورد آن مطلع خواهم شد، یعنی به معنای واقعی کلمه ظرف چند دقیقه. لازم نیست 3 ماه به عقب برگردم. من فقط باید 2 دقیقه به عقب برگردم. یک دستگاه قهوه خوب حتی زمانی برای دم کردن قهوه در 2 دقیقه ندارد، بنابراین بسیار عالی است.
این ارزشی دارد که می توان آن را بارها و بارها در هر پروژه تکرار کرد، یعنی. نه فقط اونی که رویش تنظیم کردی شما می توانید هم خود عمل را تکرار کنید و هم خود CI برای هر تغییر جدیدی که در پروژه ایجاد می کنید تکرار می شود. این به شما امکان می دهد منابع را بهینه کنید زیرا تیم شما کارآمدتر کار می کند. دیگر شرایطی نخواهید داشت که از کدی که 3 ماه پیش با آن کار کرده اید، باگ برای شما بیاید. وقتی می نشینید و دو ساعت اول را صرف تلاش برای درک آنچه که در آن زمان رخ داده است و قبل از اینکه شروع به اصلاح چیزی کنید، به اصل زمینه بپردازید، دیگر تغییر متن نخواهید داشت.
چگونه می توانیم موفقیت یا شکست این عمل را اندازه گیری کنیم؟ اگر آنچه را که ما در پروژه CI اجرا کردیم را به رئیس بزرگ گزارش دهید، او بلاهههههههههههههه. ما آن را اجرا کردیم، خوب، اما چرا، چه چیزی برای ما به ارمغان آورد، چگونه آن را اندازه گیری کنیم، چقدر درست یا نادرست آن را اجرا می کنیم؟
اولین مورد این است که، به لطف CI، ما می توانیم بیشتر و بیشتر و اغلب دقیقاً به این دلیل که کد ما به طور بالقوه پایدارتر است، مستقر می شود. به همین ترتیب زمان ما برای یافتن خطا کاهش می یابد و زمان اصلاح این خطا دقیقاً به این دلیل کاهش می یابد که همین جا و همین الان از سیستم پاسخ دریافت می کنیم که کد ما چه مشکلی دارد.
تمرین دیگری که داریم، تمرین تست اتوماسیون است که اغلب با تمرین CI همراه است. دست به دست هم می دهند.
درک چه چیزی در اینجا مهم است؟ درک این نکته مهم است که تست های ما متفاوت است. و هر تست خودکار با هدف حل مشکلات خود است. به عنوان مثال، ما تست های واحد داریم که به ما اجازه می دهد یک ماژول را جداگانه آزمایش کنیم، یعنی. چگونه در خلاء کار می کند؟ این خوبه.
ما همچنین تست های یکپارچه سازی داریم که به ما امکان می دهد بفهمیم که چگونه ماژول های مختلف با یکدیگر ادغام می شوند. آن هم خوب است.
ممکن است تست‌های اتوماسیون UI داشته باشیم که به ما امکان می‌دهد بررسی کنیم که کار با UI تا چه اندازه الزامات خاصی را که توسط مشتری تنظیم شده است و غیره برآورده می‌کند.
تست‌های خاصی که اجرا می‌کنید می‌تواند بر تعداد دفعات اجرای آنها تأثیر بگذارد. آزمون های واحد معمولاً کوتاه و کوچک نوشته می شوند. و می توان آنها را به طور منظم راه اندازی کرد.
اگر در مورد تست های اتوماسیون UI صحبت می کنیم، اگر پروژه شما کوچک باشد خوب است. تست‌های اتوماسیون UI شما ممکن است زمان کافی را ببرد. اما معمولاً تست اتوماسیون UI چیزی است که در یک پروژه بزرگ چندین ساعت طول می کشد. و اگر چند ساعت باشد خوب است. تنها چیزی که وجود دارد این است که اجرای آنها برای هر بیلد فایده ای ندارد. اجرای آنها در شب منطقی است. و وقتی همه صبح سر کار آمدند: هم آزمایش‌کنندگان و هم توسعه‌دهندگان، نوعی گزارش دریافت کردند که ما تست خودکار رابط کاربری را در شب اجرا کردیم و این نتایج را دریافت کردیم. و در اینجا، یک ساعت کار سروری که بررسی می کند محصول شما برخی از الزامات را برآورده می کند، بسیار ارزان تر از یک ساعت کار همان مهندس QA خواهد بود، حتی اگر او یک مهندس QA جوان باشد که برای غذا و تشکر کار می کند. با این حال، یک ساعت کارکرد دستگاه ارزان تر خواهد بود. به همین دلیل است که سرمایه گذاری روی آن منطقی است.
من پروژه دیگری دارم که روی آن کار کرده ام. ما دو هفته دوی سرعت در این پروژه داشتیم. این پروژه بزرگ بود، برای بخش مالی مهم بود و اشتباهی ممکن نبود. و پس از دو هفته سرعت، چرخه توسعه با یک فرآیند آزمایشی دنبال شد که 4 هفته دیگر طول کشید. سعی کنید مقیاس فاجعه را تصور کنید. ما کد را به مدت دو هفته می نویسیم، سپس آن را به نام CodeFreeze انجام می دهیم، آن را در نسخه جدیدی از برنامه بسته بندی می کنیم و آن را در اختیار آزمایش کنندگان قرار می دهیم. آزمایش کنندگان آن را برای 4 هفته دیگر آزمایش می کنند، یعنی. در حالی که آنها در حال آزمایش آن هستند، ما زمان داریم تا دو نسخه دیگر را برای آنها آماده کنیم. این یک مورد واقعا ناراحت کننده است.
و ما به آنها گفتیم که اگر می‌خواهید بهره‌وری بیشتری داشته باشید، منطقی است که روش‌های تست خودکار را اجرا کنید، زیرا این همان چیزی است که همین‌جا، همین الان به شما آسیب می‌زند.
استقرار مستمر را تمرین کنید. عالیه، ساختی رو انجام دادی این در حال حاضر خوب است. کد شما کامپایل شده است. حالا خوب است که این بیلد را روی برخی از محیط ها مستقر کنیم. بیایید در محیطی برای توسعه دهندگان بگوییم.
چرا مهم است؟ ابتدا، می توانید به میزان موفقیت خود در فرآیند استقرار نگاه کنید. من با پروژه هایی از این دست ملاقات کرده ام، وقتی می پرسم: "چگونه نسخه جدیدی از برنامه را اجرا می کنی؟"، بچه ها به من می گویند: "ما آن را مونتاژ می کنیم و در یک آرشیو فشرده بسته بندی می کنیم. ما آن را از طریق پست برای ادمین ارسال می کنیم. ادمین این آرشیو را دانلود و گسترش می دهد. و کل دفتر شروع به دعا می کند که سرور نسخه جدید را دریافت کند.
بیایید با یک چیز ساده شروع کنیم. به عنوان مثال، آنها فراموش کرده اند که CSS را در آرشیو قرار دهند یا فراموش کرده اند که هشتگ نام فایل java-script را تغییر دهند. و وقتی از سرور درخواست می کنیم، مرورگر فکر می کند که قبلاً این فایل java-script را دارد و تصمیم می گیرد آن را دانلود نکند. و یک نسخه قدیمی وجود داشت، چیزی گم شده بود. به طور کلی، ممکن است مشکلات زیادی وجود داشته باشد. بنابراین، تمرین Continuous Deployment به شما امکان می دهد حداقل آزمایش کنید که اگر یک تصویر مرجع تمیز بگیرید و آن را در یک محیط کاملاً تمیز جدید آپلود کنید، چه اتفاقی می افتد. می توانید ببینید که این به کجا منجر می شود.
همچنین، هنگامی که کد را بین یکدیگر ادغام می کنید، i.e. بین دستور، این به شما امکان می دهد تا ببینید که چگونه در رابط کاربری به نظر می رسد.
یکی از مشکلاتی که هنگام استفاده از اسکریپت وانیلی جاوا رخ می دهد، این است که دو توسعه دهنده به سرعت متغیری را با همان نام در شی پنجره اعلام کردند. و سپس، بسته به شانس شما. چه کسی فایل جاوا اسکریپت دوم بیرون کشیده شود، تغییرات دیگری را بازنویسی می کند. همچنین بسیار هیجان انگیز است. شما وارد می شوید: یک چیز برای یک نفر کار می کند، چیز دیگری برای دیگری کار نمی کند. و زمانی که همه چیز در مرحله تولید قرار می گیرد "شگفت انگیز" است.
تمرین بعدی که ما داریم، تمرین بازیابی خودکار است، یعنی بازگشت به نسخه قبلی برنامه.
چرا این برای توسعه دهندگان مهم است؟ هنوز کسانی هستند که دهه های دور و دور 90 را به یاد می آورند، زمانی که کامپیوترها بزرگ و برنامه ها کوچک بودند. و تنها راه توسعه وب از طریق PHP بود. اینطور نیست که PHP زبان بدی است، اگرچه اینطور است.
اما مشکل چیز دیگری بود. وقتی نسخه جدیدی از سایت php خود را مستقر کردیم، چگونه آن را مستقر کردیم؟ اغلب ما Far Manager یا چیز دیگری را باز کردیم. و این فایل ها را در FTP آپلود کرد. و ناگهان متوجه شدیم که یک اشکال کوچک و کوچک داریم، مثلاً فراموش کرده ایم نقطه ویرگول بگذاریم یا فراموش کرده ایم رمز عبور پایگاه داده را تغییر دهیم و یک رمز عبور برای پایگاه داده وجود دارد که روی هاست محلی است. و ما تصمیم گرفتیم به سرعت به FTP متصل شویم و فایل ها را همانجا ویرایش کنیم. این فقط آتش است! این چیزی است که در دهه 90 محبوب بود.
اما، اگر به تقویم نگاه نکرده باشید، دهه 90 تقریباً 30 سال پیش بود. حالا همه چیز کمی متفاوت اتفاق می افتد. و سعی کنید مقیاس فاجعه را تصور کنید وقتی به شما می گویند: «ما به تولید اعزام شدیم، اما مشکلی در آنجا پیش آمد. اینجا لاگین و رمز عبور FTP شما است، به تولید وصل شوید و به سرعت آن را در آنجا تعمیر کنید." اگر چاک نوریس هستید، این کار می کند. اگر نه، در این صورت شما این خطر را دارید که اگر یک باگ را برطرف کنید، 10 باگ دیگر ایجاد کنید.
حتی اگر چیز بدی به نحوی در جایی پیش بیاید، بد است، اما کشنده نیست. می توانید به نسخه قبلی که دارید برگردید. اگر درک آن در این اصطلاح آسانتر است، آن را یک نسخه پشتیبان بنامید. می توانید به این نسخه قبلی برگردید و کاربران همچنان می توانند با محصول شما کار کنند و زمان بافر کافی خواهید داشت. می توانید با آرامش، بدون عجله، همه اینها را بردارید و به صورت محلی تست کنید، آن را تعمیر کنید و سپس یک نسخه جدید آپلود کنید. انجام این کار واقعا منطقی است.
حالا بیایید سعی کنیم به نحوی دو تمرین قبلی را با هم ترکیب کنیم. سومی به نام مدیریت انتشار خواهیم داشت.
وقتی در مورد استقرار پیوسته به شکل کلاسیک آن صحبت می کنیم، می گوییم که باید کد را از شاخه ای از مخزن بکشیم، آن را کامپایل کرده و آن را مستقر کنیم. اگر همین محیط را داشته باشیم خوب است. اگر چندین محیط داشته باشیم، به این معنی است که هر بار باید کد را حتی از همان commit برداریم. ما هر بار آن را بیرون خواهیم کشید، هر بار آن را خواهیم ساخت و آن را در یک محیط جدید مستقر خواهیم کرد. اولا، این زمان است، زیرا برای ساخت یک پروژه، اگر پروژه بزرگی دارید و از دهه 90 آمده اید، ممکن است چندین ساعت طول بکشد.
علاوه بر این، غم دیگری نیز وجود دارد. هنگامی که شما می سازید، حتی روی یک دستگاه، همان منابع را می سازید، هنوز هیچ تضمینی ندارید که این دستگاه در همان حالتی باشد که در زمان ساخت قبلی بود.
فرض کنید شخصی وارد شد و DotNet را برای شما به روز کرد یا برعکس، شخصی تصمیم گرفت چیزی را حذف کند. و بعد شما ناهماهنگی شناختی دارید که از این commit دو هفته پیش ما در حال ساختن یک بیلد بودیم و همه چیز خوب بود، اما اکنون به نظر می رسد که همان ماشین، همان commit، همان کدی که می خواهیم بسازیم، اما کار نمی کند. . شما برای مدت طولانی با این موضوع سر و کار خواهید داشت و این یک واقعیت نیست که شما آن را کشف کنید. حداقل خیلی اعصابتو خراب میکنی.
بنابراین، شیوه مدیریت انتشار پیشنهاد می‌کند که یک انتزاع اضافی به نام مخزن مصنوع یا گالری یا کتابخانه معرفی کنید. شما می توانید آن را هر چه می خواهید بنامید.
ایده اصلی این است که به محض اینکه در آنجا نوعی commit داریم، مثلاً در شعبه‌ای که آماده استقرار در محیط‌های مختلف خود هستیم، برنامه‌ها را از این commit جمع‌آوری می‌کنیم و هر آنچه برای این برنامه نیاز داریم، آن را بسته بندی می‌کنیم. را در یک بایگانی فشرده قرار دهید و آن را در یک حافظه قابل اعتماد ذخیره کنید. و از این ذخیره سازی ما می توانیم این آرشیو فشرده را در هر زمان دریافت کنیم.
سپس آن را می گیریم و به طور خودکار در محیط dev مستقر می کنیم. ما آنجا مسابقه می دهیم، و اگر همه چیز خوب باشد، به صحنه اعزام می شویم. اگر همه چیز خوب باشد، ما همان آرشیو را برای تولید، همان باینری ها را که دقیقاً یک بار کامپایل شده است، مستقر می کنیم.
علاوه بر این، هنگامی که ما گالری مانند این داریم، به ما کمک می کند تا خطراتی را که در اسلاید آخر زمانی که در مورد بازگشت به نسخه قبلی صحبت کردیم، بررسی کنیم. اگر به طور تصادفی چیزی را اشتباه اجرا کردید، همیشه می توانید هر نسخه قبلی دیگر را از این گالری بردارید و به همین روش در این محیط ها بازگردانید. این به شما این امکان را می دهد که اگر مشکلی پیش آمد به راحتی به نسخه قبلی برگردید.
تمرین عالی دیگری نیز وجود دارد. همه من و شما می‌دانیم که وقتی برنامه‌های خود را به نسخه قبلی برمی‌گردانیم، ممکن است به این معنی باشد که به زیرساخت نسخه قبلی نیز نیاز داریم.
وقتی در مورد زیرساخت مجازی صحبت می کنیم، بسیاری از مردم فکر می کنند که این چیزی است که مدیران راه اندازی می کنند. و اگر مثلاً نیاز به دریافت سرور جدیدی دارید که می‌خواهید نسخه جدیدی از برنامه خود را روی آن آزمایش کنید، باید یک بلیط برای ادمین‌ها یا توسعه دهندگان بنویسید. Devops برای این کار 3 هفته زمان می برد. و بعد از 3 هفته به شما می گویند که ما یک ماشین مجازی برای شما نصب کرده ایم، با یک هسته، دو گیگابایت رم و یک سرور ویندوز بدون دات نت. شما می گویید: "اما من DotNet را می خواستم." آنها: "باشه، 3 هفته دیگر برگرد."
ایده این است که با استفاده از زیرساخت به عنوان شیوه های کد، می توانید زیرساخت مجازی خود را فقط به عنوان یک منبع دیگر در نظر بگیرید.
شاید، اگر هر یک از شما در حال توسعه برنامه های کاربردی در DotNet هستید، ممکن است درباره کتابخانه ای به نام Entity Framework شنیده باشید. و حتی ممکن است شنیده باشید که Entity Framework یکی از رویکردهایی است که مایکروسافت فعالانه در حال انجام آن است. برای کار با پایگاه داده، این رویکردی است به نام Code First. این زمانی است که شما در کد توضیح می دهید که می خواهید پایگاه داده شما چگونه به نظر برسد. و سپس برنامه را مستقر می کنید. به پایگاه داده متصل می شود، خودش تعیین می کند که کدام جداول وجود دارد و کدام جداول نیست و هر چیزی را که نیاز دارید ایجاد می کند.
شما می توانید همین کار را با زیرساخت های خود انجام دهید. تفاوتی بین اینکه برای پروژه به پایگاه داده نیاز دارید یا برای پروژه به سرور ویندوز نیاز ندارید. این فقط یک منبع است. و می توانید ایجاد این منبع را خودکار کنید، می توانید پیکربندی این منبع را خودکار کنید. بر این اساس، هر بار که بخواهید یک مفهوم جدید، یک رویکرد جدید را آزمایش کنید، نیازی به نوشتن بلیط برای devops نخواهید داشت، می توانید به سادگی یک زیرساخت جدا شده از قالب های آماده، از اسکریپت های آماده را برای خود مستقر کنید و آن را پیاده سازی کنید. تمام آزمایشات شما وجود دارد. می‌توانید این را حذف کنید، نتایجی را دریافت کنید و بیشتر در مورد آن گزارش دهید.
روش بعدی که وجود دارد و همچنین مهم است، اما افراد کمی از آن استفاده می کنند، Application Performance Monitoring است.
من می خواستم فقط یک چیز در مورد نظارت بر عملکرد برنامه بگویم. چه چیزی در مورد این عمل مهم است؟ این همان چیزی است که Application Performance Monitoring مانند تعمیر یک آپارتمان است. این یک حالت نهایی نیست، یک فرآیند است. شما باید آن را به طور منظم انجام دهید.
به روشی خوب، انجام نظارت بر عملکرد برنامه تقریباً در هر ساختنی خوب است، اگرچه، همانطور که می‌دانید، این همیشه ممکن نیست. اما، حداقل، باید برای هر نسخه انجام شود.
چرا مهم است؟ زیرا اگر به طور ناگهانی افت عملکرد را تجربه کردید، باید به وضوح دلیل آن را درک کنید. اگر تیم شما، مثلاً دو هفته‌ای اسپرینت دارد، حداقل هر دو هفته یک بار باید برنامه خود را در سرور جداگانه‌ای مستقر کنید، جایی که یک پردازنده، رم، دیسک‌ها و غیره به وضوح ثابت دارید. و همان تست‌های عملکرد را اجرا کنید. . شما نتیجه را می گیرید. ببینید چقدر نسبت به اسپرینت قبلی تغییر کرده است.
و اگر متوجه شدید که این کاهش در جایی به شدت کاهش یافته است، به این معنی است که فقط به دلیل تغییراتی است که در دو هفته گذشته رخ داده است. این به شما امکان می دهد تا مشکل را خیلی سریعتر شناسایی و برطرف کنید. و باز هم، اینها تقریباً همان معیارهایی هستند که با آن می توانید میزان موفقیت خود را اندازه گیری کنید.
تمرین بعدی ما تمرین مدیریت پیکربندی است. تعداد کمی هستند که این موضوع را جدی بگیرند. اما باور کنید، این در واقع یک چیز بسیار جدی است.
اخیراً یک داستان خنده دار وجود دارد. بچه ها نزد من آمدند و گفتند: "به ما کمک کنید تا یک ممیزی امنیتی از برنامه خود انجام دهیم." ما مدت طولانی با هم به کد نگاه کردیم، آنها در مورد برنامه به من گفتند، نمودارها را ترسیم کردند. و به علاوه یا منفی همه چیز منطقی، قابل درک، امن بود، اما یک اما وجود داشت! آنها فایل های پیکربندی را در کنترل منبع خود داشتند، از جمله فایل های تولید شده با پایگاه داده IP، با لاگین و رمز عبور برای اتصال به این پایگاه های داده و غیره.
و من می گویم: "بچه ها، خوب، شما محیط تولید خود را با یک فایروال بسته اید، اما این واقعیت که شما لاگین و رمز عبور پایگاه داده تولید را دقیقاً در کنترل منبع دارید و هر توسعه دهنده ای می تواند آن را بخواند یک خطر امنیتی بزرگ است. . و مهم نیست که برنامه شما از نظر کد چقدر ایمن باشد، اگر آن را در کنترل منبع بگذارید، هرگز هیچ ممیزی را در هیچ کجا قبول نخواهید کرد. این همون چیزیه که من درباره اش حرف می زنم.
مدیریت پیکربندی. ممکن است در محیط های مختلف تنظیمات مختلفی داشته باشیم. به عنوان مثال، ممکن است برای پایگاه‌های داده برای QA، نسخه آزمایشی، محیط تولید و غیره لاگین و رمز عبور متفاوتی داشته باشیم.
این پیکربندی همچنین می تواند خودکار باشد. همیشه باید از خود برنامه جدا باشد. چرا؟ از آنجا که شما برنامه را یک بار ساخته اید، و سپس برنامه اهمیتی نمی دهد که آیا از طریق فلان IP به سرور SQL متصل می شوید یا فلان IP، باید به همان صورت کار کند. بنابراین، اگر ناگهان یکی از شما هنوز رشته اتصال را در کد هاردکد می کند، به یاد داشته باشید که اگر در پروژه مشابهی با من باشید، شما را پیدا می کنم و مجازات می کنم. این همیشه در یک پیکربندی جداگانه قرار می گیرد، به عنوان مثال، در web.config.
و این پیکربندی قبلاً به طور جداگانه مدیریت شده است، یعنی دقیقاً لحظه ای است که یک توسعه دهنده و یک مدیر می توانند بیایند و در یک اتاق بنشینند. و توسعه‌دهنده می‌تواند بگوید: «ببینید، اینجا باینری‌های برنامه من است. آنها کار میکنند. برنامه برای کار به یک پایگاه داده نیاز دارد. در اینجا در کنار باینری ها یک فایل وجود دارد. در این فایل این قسمت مسئول ورود است، این برای رمز عبور، این برای IP است. آن را در هر جایی مستقر کنید." و برای ادمین ساده و واضح است. او با مدیریت این پیکربندی می‌تواند آن را در هر کجا مستقر کند.
و آخرین تمرینی که می خواهم در مورد آن صحبت کنم تمرینی است که بسیار بسیار مرتبط با ابرها است. و اگر در فضای ابری کار کنید حداکثر اثر را به ارمغان می آورد. این حذف خودکار محیط شماست.
می دانم که در این کنفرانس چند نفر از تیم هایی که با آنها کار می کنم حضور دارند. و با تمام تیم هایی که با آنها کار می کنم، از این تمرین استفاده می کنیم.
چرا؟ البته، اگر هر توسعه دهنده یک ماشین مجازی داشته باشد که 24/7 کار کند، عالی خواهد بود. اما شاید این خبر برای شما باشد، شاید توجه نکرده باشید، اما خود توسعه دهنده 24/7 کار نمی کند. یک توسعه دهنده معمولاً 8 ساعت در روز کار می کند. حتی اگر زود به سر کار بیاید، یک ناهار بزرگ می خورد که در طی آن به ورزشگاه می رود. بگذارید 12 ساعت در روز باشد که توسعه دهنده واقعاً از این منابع استفاده می کند. طبق قانون ما از 5 روز در هفته 7 روز داریم که روز کاری محسوب می شود.
بر این اساس در روزهای کاری این دستگاه نباید 24 ساعت کار کند بلکه فقط 12 ساعت کار می کند و در روزهای آخر هفته این دستگاه اصلا نباید کار کند. به نظر می رسد همه چیز بسیار ساده است، اما در اینجا چه چیزی مهم است که بگوییم؟ با اجرای این تمرین ساده در این برنامه اولیه، به شما این امکان را می دهد که هزینه نگهداری این محیط ها را تا 70% کاهش دهید، یعنی قیمت برنامه نویس، QA، نسخه آزمایشی، محیط خود را گرفته اید و آن را بر 3 تقسیم کرده اید.
سوال این است که با بقیه پول چه باید کرد؟ برای مثال، توسعه‌دهندگان باید ReSharper را بخرند، اگر قبلاً این کار را نکرده‌اند. یا یک کوکتل مهمانی بگیرید. اگر قبلاً یک محیط داشتید که هم dev و هم QA در آن چریدند و تمام، اکنون می توانید 3 محیط مختلف بسازید که ایزوله می شوند و افراد با یکدیگر تداخل نمی کنند.
در مورد اسلاید با اندازه گیری عملکرد پیوسته، اگر در پروژه 1 رکورد در بانک اطلاعاتی داشتیم، دو ماه بعد یک میلیون وجود دارد، چگونه می توانیم عملکرد را مقایسه کنیم؟ چگونه بفهمیم چرا و چه فایده ای برای اندازه گیری عملکرد دارد؟
این سؤال خوبی است، زیرا همیشه باید عملکرد را بر روی همان منابع اندازه گیری کنید. یعنی شما کد جدیدی را منتشر می کنید، عملکرد را روی کد جدید اندازه می گیرید. به عنوان مثال، شما باید سناریوهای مختلف عملکرد را آزمایش کنید، فرض کنید می خواهید عملکرد برنامه را در یک بار سبک، که در آن 1 کاربر وجود دارد و حجم پایگاه داده 000 گیگابایت است، آزمایش کنید. شما آن را اندازه گرفتید و اعداد را دریافت کردید. در مرحله بعد سناریوی دیگری را در نظر می گیریم. به عنوان مثال، 5 کاربر، حجم پایگاه داده 5 ترابایت. ما نتایج را دریافت کردیم و آنها را به یاد آوردیم.
اینجا چه چیزی مهم است؟ نکته مهم در اینجا این است که بسته به سناریو، حجم داده، تعداد کاربران همزمان و غیره ممکن است با محدودیت های خاصی مواجه شوید. مثلاً به حد مجاز کارت شبکه یا در حد یک هارد دیسک یا تا حد توانایی های پردازنده. این چیزی است که برای شما مهم است که درک کنید. در سناریوهای مختلف شما با محدودیت های خاصی مواجه می شوید. و شما باید اعداد را در هنگام ضربه زدن به آنها درک کنید.
آیا ما در مورد اندازه گیری عملکرد در یک محیط آزمایشی خاص صحبت می کنیم؟ یعنی این تولید نیست؟
بله، این تولید نیست، این یک محیط تست است که همیشه یکسان است تا بتوانید آن را با اندازه گیری های قبلی مقایسه کنید.
فهمیدم ممنون
اگر سوالی وجود ندارد، فکر می کنم می توانیم تمام کنیم. متشکرم!
منبع: www.habr.com