ما یک بار سیستم مدیریت اسناد الکترونیکی را برای مشتری در یک مرکز عرضه کردیم. و سپس به یک شی دیگر. و یکی دیگر. و در چهارم، و در پنجم. ما آنقدر سرگردان شدیم که به 10 شیء توزیع شده رسیدیم. بسیار قدرتمند بود... به خصوص زمانی که به ارائه تغییرات رسیدیم. به عنوان بخشی از تحویل به مدار تولید، 5 سناریو از سیستم آزمایش در نهایت به 10 ساعت و 6-7 کارمند نیاز داشت. چنین هزینه هایی ما را مجبور کرد که تا حد امکان به ندرت تحویل دهیم. پس از سه سال کار، ما نتوانستیم آن را تحمل کنیم و تصمیم گرفتیم پروژه را با مقداری DevOps چاشنی کنیم.
اکنون تمام تست ها در 3 ساعت انجام می شود و 3 نفر در آن شرکت می کنند: یک مهندس و دو آزمایش کننده. پیشرفت ها به وضوح در اعداد بیان می شوند و منجر به کاهش TTM بسیار محبوب می شوند. در تجربه ما، تعداد مشتریانی که می توانند از DevOps بهره مند شوند، بسیار بیشتر از کسانی هستند که حتی در مورد آن می دانند. بنابراین، برای نزدیک‌تر کردن DevOps به مردم، یک سازنده ساده ایجاد کرده‌ایم که در این پست بیشتر در مورد آن صحبت خواهیم کرد.
حالا بیایید با جزئیات بیشتر به شما بگوییم. یک شرکت انرژی در حال استقرار یک سیستم مدیریت اسناد فنی در 10 تاسیسات بزرگ است. پیمایش پروژه‌های در این مقیاس بدون DevOps آسان نیست، زیرا سهم بزرگی از کار دستی کار را تا حد زیادی به تأخیر می‌اندازد و همچنین کیفیت را کاهش می‌دهد - همه کارهای دستی مملو از خطا است. از سوی دیگر، پروژه هایی وجود دارد که تنها یک نصب وجود دارد، اما همه چیز باید به طور خودکار، دائما و بدون شکست کار کند - به عنوان مثال، همان سیستم های جریان اسناد در سازمان های بزرگ یکپارچه. در غیر این صورت، شخصی تنظیمات را به صورت دستی انجام می دهد، دستورالعمل های استقرار را فراموش می کند - و در نتیجه، در تولید تنظیمات از بین می رود و همه چیز فرو می ریزد.
معمولاً ما از طریق قرارداد با مشتری کار می کنیم و در این مورد علایق ما اندکی از هم جدا می شود. مشتری دقیقاً در چارچوب بودجه و مشخصات فنی به پروژه نگاه می کند. توضیح دادن مزایای شیوه های مختلف DevOps که در مشخصات فنی گنجانده نشده اند، می تواند دشوار باشد. اگر او علاقه مند به انتشار سریع با ارزش تجاری افزوده یا ساخت خط لوله اتوماسیون باشد، چه؟
افسوس، هنگام کار با هزینه از پیش تایید شده، این علاقه همیشه پیدا نمی شود. در عمل ما، موردی وجود داشت که مجبور شدیم توسعه یک پیمانکار بی وجدان و بی دقت را انتخاب کنیم. وحشتناک بود: هیچ کد منبع به‌روزی وجود نداشت، پایه کد همان سیستم در نصب‌های مختلف متفاوت بود، اسناد تا حدی وجود نداشت، و تا حدی کیفیت وحشتناکی داشت. البته مشتری کنترلی روی کد منبع، اسمبلی، انتشار و غیره نداشت.
تاکنون، همه درباره DevOps نمی‌دانند، اما به محض اینکه در مورد مزایای آن صحبت می‌کنیم، در مورد صرفه‌جویی در منابع واقعی، چشم همه مشتریان روشن می‌شود. بنابراین تعداد درخواست هایی که شامل DevOps می شوند در طول زمان در حال افزایش است. در اینجا، برای اینکه به راحتی با مشتریان به یک زبان صحبت کنیم، باید به سرعت مشکلات تجاری و شیوه‌های DevOps را به هم وصل کنیم که به ایجاد یک خط لوله توسعه مناسب کمک می‌کند.
بنابراین، ما از یک طرف مجموعه ای از مشکلات داریم، از طرف دیگر دانش، شیوه ها و ابزار DevOps را داریم. چرا تجربه را با همه به اشتراک نمی گذارید؟
ایجاد سازنده DevOps
Agile مانیفست خاص خود را دارد. ITIL متدولوژی خاص خود را دارد. DevOps کمتر خوش شانس است - هنوز قالب ها و استانداردها را به دست نیاورده است. با اينكه تعیین بلوغ شرکت ها بر اساس ارزیابی توسعه و رویه های عملیاتی آنها.
خوشبختانه شرکت معروف گارتنر در سال 2014 و اقدامات کلیدی DevOps و روابط بین آنها را تجزیه و تحلیل کرد. بر این اساس یک اینفوگرافیک منتشر کردم:
ما آن را به عنوان مبنایی برای خود در نظر گرفتیم . هر یک از چهار حوزه دارای مجموعه ای از ابزارها هستند - ما آنها را در یک پایگاه داده جمع آوری کردیم، محبوب ترین آنها را شناسایی کردیم، نقاط ادغام و مکانیسم های بهینه سازی مناسب را شناسایی کردیم. در کل معلوم شد 36 تمرین و 115 ابزارکه یک چهارم آن نرم افزار متن باز یا رایگان است. در مرحله بعد، در مورد آنچه در هر زمینه به دست آورده ایم و به عنوان مثال در مورد نحوه اجرای این پروژه در پروژه ایجاد مدیریت اسناد فنی که پست را با آن شروع کردیم صحبت خواهیم کرد.
فرایندها
در پروژه بدنام EDMS، سیستم مدیریت اسناد فنی بر اساس همان طرح در هر یک از 10 شی مستقر شد. نصب شامل 4 سرور است: سرور پایگاه داده، سرور برنامه، نمایه سازی متن کامل و مدیریت محتوا. در نصب، آنها در یک گره واحد عمل می کنند و در مرکز داده در تاسیسات قرار دارند. همه اشیا در زیرساخت کمی متفاوت هستند، اما این در تعامل جهانی تداخلی ایجاد نمی کند.
ابتدا، طبق رویه‌های DevOps، زیرساخت را به صورت محلی خودکار کردیم، سپس تحویل را به مدار آزمایش و سپس به محصول مشتری رساندیم. هر فرآیند مرحله به مرحله انجام شد. تنظیمات محیط در سیستم کد منبع ثابت می شوند، با در نظر گرفتن اینکه کیت توزیع برای به روز رسانی خودکار کامپایل شده است. در صورت تغییرات پیکربندی، مهندسان به سادگی باید تغییرات مناسب را در سیستم کنترل نسخه ایجاد کنند - و سپس به روز رسانی خودکار بدون مشکل انجام می شود.
به لطف این رویکرد، روند آزمایش تا حد زیادی ساده شده است. پیش از این، این پروژه آزمایش کننده هایی داشت که هیچ کاری جز به روز رسانی دستی پایه ها انجام نمی دادند. حالا آنها فقط می آیند، می بینند که همه چیز کار می کند و کارهای مفیدتری انجام می دهند. هر به روز رسانی به طور خودکار آزمایش می شود - از سطح سطح تا اتوماسیون سناریوهای تجاری. نتایج به عنوان گزارش های جداگانه در TestRail ارسال می شود.
فرهنگ
آزمایش مداوم به بهترین وجه از طریق مثال طراحی آزمون توضیح داده می شود. آزمایش سیستمی که هنوز وجود ندارد یک کار خلاقانه است. هنگام نوشتن یک طرح تست، باید بدانید که چگونه به درستی تست کنید و کدام شاخه ها را دنبال کنید. و همچنین تعادلی بین زمان و بودجه برای تعیین تعداد بهینه چک پیدا کنید. مهم است که دقیقاً آزمایشات لازم را انتخاب کنید، به نحوه تعامل کاربر با سیستم فکر کنید، محیط و عوامل خارجی احتمالی را در نظر بگیرید. انجام این کار بدون آزمایش مداوم غیرممکن است.
حالا در مورد فرهنگ تعامل. پیش از این، دو طرف مخالف وجود داشت - مهندسان و توسعه دهندگان. توسعه دهندگان گفتند: "ما اهمیتی نمی دهیم که چگونه راه اندازی می شود. شما مهندس هستید، شما باهوش هستید، مطمئن شوید که بدون شکست کار می کند.. مهندسان پاسخ دادند: شما توسعه دهندگان بیش از حد بی دقت هستید. بیایید بیشتر مراقب باشیم و انتشارات شما را کمتر پخش خواهیم کرد. زیرا هر بار که یک کد لو رفته به ما می‌دهید، نحوه تعامل برای ما روشن نیست.». این یک موضوع تعامل فرهنگی است که از دیدگاه DevOps ساختار متفاوتی دارد. در اینجا، هم مهندسان و هم توسعه دهندگان بخشی از یک تیم واحد هستند که بر روی نرم افزارهای دائمی در حال تغییر، اما در عین حال قابل اعتماد تمرکز دارند.
در همان تیم، متخصصان مصمم هستند که به یکدیگر کمک کنند. همانطور که قبلا بود؟ به عنوان مثال، چند دستورالعمل استقرار ضخیم در حال آماده شدن بود، حدود 50 صفحه. مهندس آن را خواند، چیزی متوجه نشد، فحش داد و در ساعت سه صبح از توسعه دهنده خواست نظر بدهد. توسعه دهنده نظر داد و همچنین فحش داد - در نهایت هیچ کس خوشحال نشد. به علاوه، به طور طبیعی، برخی از اشتباهات وجود داشت، زیرا شما نمی توانید همه چیز را در دستورالعمل ها به خاطر بسپارید. و اکنون مهندس، همراه با توسعه دهنده، در حال نوشتن یک اسکریپت برای استقرار خودکار زیرساخت نرم افزار کاربردی هستند. و عملاً به یک زبان با یکدیگر صحبت می کنند.
مردم
اندازه تیم با توجه به دامنه به روز رسانی تعیین می شود. این تیم در طول شکل گیری تحویل استخدام می شود؛ این تیم شامل علاقه مندان از تیم کلی پروژه می شود. سپس یک برنامه به روز رسانی با مسئولین هر مرحله نوشته می شود و تیم گزارش می دهد که پیشرفت می کند. همه اعضای تیم قابل تعویض هستند. به عنوان بخشی از تیم، ما همچنین یک توسعه دهنده پشتیبان داریم، اما او تقریباً هرگز مجبور به اتصال نیست.
تکنولوژی
در نمودار فناوری، چند نکته برجسته شده است، اما در زیر آنها یک سری فناوری وجود دارد - می توانید یک کتاب کامل با توضیحات آنها منتشر کنید. بنابراین ما جالب ترین ها را برجسته می کنیم.
زیرساخت به عنوان کد
در حال حاضر، احتمالا، این مفهوم هیچ کس را شگفت زده نخواهد کرد، اما قبلاً توصیف زیرساخت ها بسیار مورد نظر باقی مانده است. ، محیط های آزمایش منحصر به فرد بودند، آنها را گرامی داشتند و گرامی داشتند، ذرات گرد و غبار از روی آنها دمیده شدند.
امروزه هیچ کس از آزمایش کردن نمی ترسد. تصاویر اولیه ماشین های مجازی و سناریوهای آماده برای استقرار محیط ها وجود دارد. تمام قالب ها و اسکریپت ها در یک سیستم کنترل نسخه ذخیره می شوند و به سرعت به روز می شوند. پیش از این، هنگامی که لازم بود بسته ای را به یک غرفه تحویل دهید، شکاف پیکربندی ظاهر شد. اکنون فقط باید یک خط به کد منبع اضافه کنید.
علاوه بر اسکریپت‌های زیرساخت و خطوط لوله، رویکرد Documentation as a Code نیز برای مستندسازی استفاده می‌شود. به لطف این، اتصال افراد جدید به پروژه، معرفی آنها به سیستم بر اساس عملکردهای توصیف شده، به عنوان مثال، در طرح آزمایشی و همچنین استفاده مجدد از موارد آزمایش آسان است.
تحویل و نظارت مستمر
در مورد DevOps، در مورد نحوه انتخاب ابزارهایی برای اجرای تحویل و نظارت مستمر صحبت کردیم. اغلب نیازی به بازنویسی چیزی نیست - کافی است از اسکریپت های نوشته شده قبلی استفاده کنید، یکپارچگی بین اجزا را به درستی ایجاد کنید و یک کنسول مدیریت مشترک ایجاد کنید. و تمام فرآیندها را می توان با استفاده از یک دکمه یا برنامه راه اندازی کرد.
در زبان انگلیسی مفاهیم مختلفی وجود دارد، Continuous Delivery و Continuous Deployment. هر دو را می توان به عنوان "تحویل مداوم" ترجمه کرد، اما در واقع تفاوت جزئی بین آنها وجود دارد. در پروژه ما برای جریان اسناد فنی یک شرکت انرژی توزیع شده، از تحویل استفاده می شود - زمانی که نصب برای تولید به دستور انجام می شود. در Deployment، نصب به صورت خودکار انجام می شود. تحویل مستمر در این پروژه به طور کلی تبدیل شده است بخش مرکزی DevOps.
به طور کلی، با جمع‌آوری پارامترهای خاص، می‌توانید به وضوح بفهمید که چرا تمرین‌های DevOps مفید هستند. و این را به مدیریت که واقعا اعداد را دوست دارد برسانید. تعداد کل راه‌اندازی‌ها، زمان اجرای مراحل اسکریپت، سهم راه‌اندازی موفقیت‌آمیز - همه این‌ها مستقیماً بر زمان مورد علاقه همه برای بازاریابی تأثیر می‌گذارد، یعنی زمان از commit به سیستم کنترل نسخه تا انتشار نسخه در یک محیط تولید. مهندسان با اجرای ابزارهای لازم، شاخص های ارزشمندی را از طریق پست دریافت می کنند و مدیر پروژه آنها را روی داشبورد مشاهده می کند. به این ترتیب می توانید فوراً مزایای ابزارهای جدید را ارزیابی کنید. و می توانید با استفاده از طراح DevOps آنها را روی زیرساخت خود امتحان کنید.
چه کسی به ما نیاز خواهد داشت ?
تظاهر نکنیم: برای شروع، او برای ما مفید شد. همانطور که قبلاً گفتیم، شما باید با مشتری به یک زبان صحبت کنید و با کمک طراح DevOps می توانیم به سرعت پایه و اساس چنین مکالمه ای را ترسیم کنیم. متخصصان کسب و کار قادر خواهند بود خودشان آنچه را که نیاز دارند ارزیابی کنند و در نتیجه سریعتر توسعه یابند. ما سعی کردیم طراح را تا حد امکان دقیق کنیم و مجموعه‌ای از توضیحات را اضافه کردیم تا هر کاربر بفهمد چه چیزی را انتخاب می‌کند.
فرمت طراح به شما امکان می دهد تا پیشرفت های موجود شرکت را در فرآیندهای ساختمانی و اتوماسیون در نظر بگیرید. اگر فقط بتوانید راه حل هایی را انتخاب کنید که به خوبی با فرآیندهای موجود ادغام می شوند و به سادگی می توانند شکاف ها را پر کنند، نیازی به خراب کردن همه چیز و بازسازی آن نیست.
شاید پیشرفت شما قبلاً به سطح بالاتری رفته باشد و ابزار ما بسیار "کاپیتانی" به نظر برسد. اما ما آن را برای خود مفید می دانیم و امیدواریم که برای برخی از خوانندگان مفید واقع شود. ما به شما یادآوری می کنیم به طراح - اگر چیزی باشد، نمودار را بلافاصله پس از وارد کردن داده های اولیه دریافت می کنید. از نظرات و مطالب اضافه شما سپاسگزار خواهیم بود.
منبع: www.habr.com