ظهور DevOps
ایدهی اولیه devops توسط مشاوری از بلژیک به نام Patrick Debois شکل گرفت. این مشاور از فاصله و تضاد میان تیم Dev و Ops ناراضی بود و مشکلات ناشی از این تضاد را در شرکت ها میدید.
در سال ۲۰۰۸ در یک کنفرانس در بارهی زیرساخت چابک (Agile Infrastructure) شرکت میکند و این ارایه اولین جرقه ها را در ذهن Debios ایجاد میکند. در سال ۲۰۰۹ Debios اولین کنفرانس "DevOpsDays" را در شهر گِنت، بلژیک برگزار کرد و اصطلاح DevOps که مخفف Development + Operations است، در همین زمان معرفی شد. هدف از این حرکت، افزایش همکاری بین تیمهای Dev و Ops با تکیه بر ایجاد فرهنگ مشترک، خودکارسازی فرایندها بود.
DevOps
همانطور که پیشتر گفته شد در سازمان های نرمافزاری تیم Dev فقط بر این موضوع متمرکز بود که کد را بنویسد و در نهایت آن را به تیم Ops برای استقرار تحویل دهد. در این شیوه تیم Dev هیچ درکی از محیط Ops نداشت و تیم Ops نیز شناخت کافی از محیط و نحوهی توسعه برنامه نداشت.
DevOps آمد تا این شکاف را پر کند. این شیوه با قرار گرفتن در بین تیم Dev و تیم Ops تضاد و ناهماهنگی این دو را برطرف کرد. DevOps توانست با اصولی که ارائه داد ارتباط خوبی میان این دو تیم برقرار کند و به نوعی با قرار دادن یک خط تولید (یا pipeline) خروجی تیم Dev را بدون درگیر شدن تیم Ops به محیط تولید برساند.
با استفاده از اصول DevOps تیم Dev میتواند تغییرات را در لحظه روی کد ایجاد کند و آن را روی ورژنکنترل commit کند و به صورت خودکار کد اجرا شود، تست شود و در صورت نبود خطا، در نهایت به محیط تولید برسد. این کار ها کاملا به صورت اتوماتیک انجام میشود به گونهی که درگیری میان دو تیم Dev و Ops را از بین ببرد.
اصول DevOps
برای پیاده سازی DevOps باید اصول DevOps نیز در سازمان ها پیاده و رعایت شود. DevOps دارای اصول زیادی است که چند تا از آنها اشاره میکنیم:
خودکار سازی(automation)
این اصل بر این تاکید دارد که هرچیزی که قرار است بیشتر از یک بار در سازمان تکرار شود باید اتوماتیک شود و کار تکراری را هربار انسان انجام ندهد. یعنی از لحظهی که برنامه نویس تغییری روی کد اصلی ایجاد میکند و آن را روی ورژن کنترل commit میکند باید فرایند تست، اجرا و استقرار کد در محیط تولید به صورت اتوماتیک باشد.
یک از مزیت های دیگر خودکار سازی فرایند، ثبات در نحوهی انتقال برنامه از محیط Dev به محیط تولید است. یعنی هر بار فرایند انتقال به یک شیوه انجام میشود و اطمینان میدهد که کار های تکراری در هر بار تکرار به یک صورت انجام میشود که این کاملا برخلاف شیوهی غیر اتوماتیک آن است که ممکن است بسته به فردی که آن کار را انجام میدهد هر بار به یک شیوه باشد که این باعث بیثباتی محیط تولید میشود.
یکپارچه سازی مداوم(continuous integration) یا CI
در گذشته تیم Dev تغییراتی که روی کد صورت میگرفت را تا انجام و تکمیل شدن در branch اصلی merge نمیکردند و گاهی اوقات مجبور بودند در دوره های یک ماهه یا چند ماهه تغییرات را در branch اصلی merge کنند و آن را به محیط تولید ببرند. این رویه باعث دیر رسیدن آپدیت ها و تغییرات به محیط تولید و در نهایت به دست کاربران بود و گاهی اوقات باگ های که در سیستم وجود داشت در چرخه های زمانی طولانی درست میشد و تا مدت ها مشکل در سیستم وجود داشت.
با continuous integration توسعه دهندگان میتوانند به صورت مداوم تغییرات خود را به استفاده از ورژن کنترل ها (مانند گیت) commit کنند. با سیستم CI به صورت اتوماتیک کدها اجرا و تست میشوند و در هر خطای در روند اجرا و تست را گزارش میدهد.
در کل CI به محیط build و تست کردن کد قبل از انتشار آن در محیط تولید اشاره دارد.
تصمیمات بر اساس داده (data-driven decision-making)
در DevOps بر اساس داده و اطلاعات از قبل جمعآوری شده تصمیمات گرفته میشوند. یعنی صرفا به خاطر محبوبیت یک ابزار از آن در سیستم استفاده نمیکنیم و باید بر اساس داده های موجود در یک ابزار را انتخاب میکنیم. برای مثال در انتخاب یک فریمورک برای نوشتن بخشی از سیستم باید بر اساس benchmark ها، دادههای موجود و تجربیات سازمان های دیگر در استفاده از این فریمورک این ابزار انتخاب یا رد شود.
برای مثال در سیستمهای سازمانی میتوان تصمیمات را بر اساس داده های که از system log ها و بازخورد کاربران گرفت.
Continuous Delivery یا CD
CD در DevOps به فرایندی گفته میشود که تست ها و آزمایش های نهایی روی کد انجام شده و آماده قرار گرفتن در بخش production است. فرایند CD یک مرحله بعد از CI صورت میپذیرد. در فرایند CI کد Build و unit test روی آن انجام شده سپس در بخش CD تست های نهایی مانند UI test یا load test روی آن انجام میشود.
فرق بین Continuous Delivery با Continuous Deployment
در continuous delivery بعد از این که تست های نهایی روی آن انجام شد برنامه به محیط production واقعی نمیرود یعنی تغییرات ایجاد شده فعلا به دست کاربر نهایی نمیرسد بلکه در یک محیط قبل از production قرار میگیرد و منتظر تایید دستی برای رفتن به محیط production میشود.
در continuous deployment بعد تست های نهایی نیاز به تایید دستی برای گذاشتن برنامه در production نیست بلکه به صورت خودکار این کار صورت می پذیرد.
Logging and Monitoring
Logging به معنی ثبت رخدادهای سیستمی است، یعنی تمام اتفاقات درون سیستم و سرویس های فعال درون سیستم را ثبت کنیم. این کار به پیدا کردن مشکلات و نحوهی کار لحظهی سیستم کمک میکند. لاگها بسته به هر سیستمی در مدت زمان مشخصی روی سیستم ذخیره میشوند و در صورت نیاز برای رفع مشکلات می توان به آنها دسترسی داشت.
Monitoring به معنی نظارت و بررسی لحظهی سیستم است. بدین معنی که سیستم در چه وضعیتی است، چه اندازه از منابع سیستم مصرف شده است و تعداد سرورهای فعال در کل سیستم را میتوان نظارت کرد.
DevOps یک فرهنگ سازمانی
جدا از مباحث فنی، DevOps یک فرهنگ سازمانی برای مدیریت تیم ها نیز است و تمرکز اصلی آن بر تعامل، همکاری و مسئولیت پذیری اشخاص و تیم ها است.
همکاری(Collaboration)
این بحث از اصول پایهی DevOps است که بر شکستن شکاف بین تیمها مانند تیم Dev و Ops تمرکز دارد و تیم ها را به همکاری و درک بهتر از نحوهی کار دیگر تیم ها دعوت میکند. برای مثال در این فرهنگ تیم Dev از زیرساخت سیستم و نحوه ی استقرار برنامه که مربوط به تیم Ops است درک دارد و با این تیم در تعامل است و تیم Dev نیز درکی از نحوه ی پیاده سازی کد که مربوط به تیم Dev است دارد.
ارتباط(Communication)
در devops ارتباط به معنی ارتباط میان تمام اعضای مشارکت کننده در توسعه محصول است. یعنی یک ارتباط شفاف، سریع و موثر میان تیم ها، چون devops به دنبال همکاری نزدیک میان بخش های مختلف چرخه تولید نرمافزار است. رفع سیلوها: در سازمان های سنتی تیم ها مستقل از هم کار میکنند و همین باعث تاخیر و مشکلات زیادی میشود. ارتباط در devops این مشکل را حل میکند. افزایش سرعت توسعه و استقرار:وقتی اطلاعات به سرعت منتقل شود، تصمیمگیریها هم سریعتر خواهد بود. کاهش خطاها و سوءتفاهمها: مستندسازی و گفتگو شفاف باعث میشود همه اعضای تیم درک درستی از وظایف و تغییرات داشته باشند.
Devops، یک فرایند خودکار سازی
خودکارسازی در DevOps یعنی «اتوماتیک کردن» هر کاری در چرخهٔ توسعه و انتشار نرمافزار که تکراری، دارای خطا یا زمانبره (از نوشتن کد تا تولید زیرساخت و مانیتورینگ) تا تیم قادر باشد با سرعت و ثبات بیشتری تغییرات را به دست مشتری برساند. به جای کلیکهای دستی و اسکریپتهای پراکنده، فرایندها داخل pipeline ها و ابزارهای اتوماسیون جریان میگیرند.
بخشهای خودکار سازی
Infrastructure as Code
تعریف زیر ساخت به صورت کد، بدین معنی که منابع زیرساخت مانند منابع سرور به صورت کد تنظیم شوند و به صورت اتوماتیک در صورت لزوم این منابع افزایش یا کاهش یابند. این کار باعث میشود که مدیریت زیرساخت راحت تر شود و در مواقعی مانند اضافه کردن سرور به زیرساخت نیاز به تنظیم دستی نیست و میتوان از کدها و config های از پیش نوشته شده استفاده کرد. Terraform, Pulumi ابزار های هستند که میتوان برای IaC از آن استفاده کرد.
Configuration Management
میتوان پیکربندی سرور ها را به کد تبدیل کرد به گونه ی که یک بار کد را نوشت و برای سرور های بعدی که در طول چرخه توسعه اضافه میشوند از همان دوباره استفاده کرد. Ansible, chef ابزار های برای مدیریت و پیکربندی سرور ها باهم اند.