تحویل مستمر

مطلبی که می‌خوانید ترجمه‌ قسمت ۲۲۱ از رادیو مهندسی نرم‌افزار است. رادیو مهندسی نرم‌افزار هر یکی دو هفته یک بار مصاحبه‌ای درباره‌ یکی از موضوعات حوزه‌ مهندسی نرم‌افزار با افراد خبره و با تجربه در موضوع مورد بحث ترتیب می‌دهد.

در این قسمت یوهانز تونز با جز هامبل در مورد تحویل مستمر (continuous delivery) صحبت می‌کند. جز هامبل هم‌اکنون نائب‌رییس شرکت Chef است. او ۱۴ سال سابقه کار در صنعت IT دارد. به ‌غیر از کار توسعه و مدیریت، مشاوره هم می‌کند. نکته جالب این است که او در ۱۱ سالگی کار برنامه‌نویسی را آغاز کرد و مجذوب کامپیوترهای خانگی ZX Spectrum شد. اما در ادامه از دانشگاه آکسفورد، لیسانس فیزیک و فلسفه گرفت. احتمالاً بیشتر افراد ایشان را از کتاب Continuous Delivery و کتاب Lean Enterprise می‌شناسند.

در این مصاحبه، در بحث تحویل مستمر از موضوع‌های خیلی متنوعی صحبت می‌شود: تحویل مستمر و اینکه چطور در GoCD و فریم‌ویر HP انجام شد، منافع تحویل مستمر برای توسعه‌دهنده‌ها، قانون کانوِی و تیم‌های فراعملکردی (cross-functional)، نسخه دادنِ بدون ترس، رفع‌خطای به جلو (fix-forward)، استقرار آبی/سبز، تست A/B، ریشه‌های تحویل مستمر در توسعه ترکه‌ای (lean)، زمان چرخه (cycle time) از ورود کد تا اجرا شدن آن، خط لوله استقرار (deployment pipeline)، مجزا کردن انتشار از استقرار، ارتباط بحث با DevOps، تحویل مستمر در محیط‌های پیرو مقررات، اینکه «همه در ارتباط با فرآیند تحویل مسئولیت دارند»، تغییر فرهنگ به DevOps، متوقف کردن خط تولید، اینکه «همه چیز باید در مخزن کنترل نسخ (version control) باشد»، توسعه مبتنی بر شاخه‌ اصلی (trunk-based development)، مدیریت پیکربندی، مجازی‌سازی محفظه‌ها (container) و ... .

آیا ممکن است به طور خیلی خلاصه به ما بگویید که تحویل مستمر چیست؟

قطعاً. تحویل مستمر، برآمده از تجربه‌هایی است که من و گروهی از افراد دیگر در شرکت ThoughtWorks داشتیم. ما روی پروژه‌های پیچیده و کاملاً بزرگی کار می‌کردیم و نسخه‌دادن، همواره فرآیند رنج‌آوری داشت. در جایی، کار توسعه انجام می‌شد و بعد نرم‌افزار باید جای دیگری برای اجرا در محیط عملیاتی برپا می‌شد و این کار فرآیند خیلی دشوار و رنج‌آوری داشت. ThoughtWorks در ارتباط با یکپارچه‌سازی مستمر (continuous integration) یکی از پیشگامان و از شرکت‌هایی بود که به محبوب شدن آن کمک کرده بود. بنابراین ما در یکپارچه‌سازی منظم کدها و اجرای منظم تست‌های خودکار خیلی خوب بودیم، اما فهمیدیم تنها این‌ها برای اینکه محصول برای عملیاتی شدن آماده شود، کافی نیست.

یکی از پروژه‌هایی که من در آن کار می‌کردم و این مسأله را برایم روشن کرد یک سیستم تأمین پهنای باند بود که برای یک ISP نوشتیم. ما سیستم را بر روی لپ‌تاپ‌های ویندوزی توسعه می‌دادیم اما قرار بود سیستم بر روی یک خوشه سولاریسی استقرار یابد. اولین باری که توانستیم به جایی مشابه با محیط عملیاتی آن دست پیدا کنیم، بیش از ۶ ماه از پروژه گذشته بود و ۲-۳ هفته، از ما وقت گرفت تا توانستیم آن را مستقر کنیم و وقتی آن را مستقر کردیم متوجه مشکلات معماری‌مان شدیم که به علت فرضیات بدی بود که افراد کرده بودند. مثلاً استفاده از حافظه پنهان (cache) بر روی فایل سیستمِ لپ‌تاپ‌های ویندوزی خوب کار می‌کند اما بر روی یک خوشه از کامپیوترها کار نمی‌کند زیرا در آنجا هر سرویسی، فایل سیستم متفاوتی دارد. ما متوجه این مشکلات شدیم اما برطرف کردن آنها واقعاً پرهزینه بود. همین‌طور برای کمک در مستقر کردن سیستم تعدادی اسکریپت‌های خودکار داشتیم که روی ant اجرا می‌شدند اما تیم عملیات (operation team) علاقه‌ای به استفاده از ant نداشت. ما از آنها پرسیدیم می‌خواهید برای عملیاتی کردن سیستم از چه استفاده کنید؟ آنها گفتند که ما فقط از bash استفاده می‌کنیم. بنابراین مجبور شدیم برای استقرار bash بنویسیم. در انتها یک تیم از بهترین‌های ما یک نرم‌افزار اختراع کرده و توسعه داد تا بتوانیم سیستم را به‌صورت منظم در محیط تست مستقر کنیم و بازخورد‌های تست را دریافت کنیم و بعد بتوانیم سیستم را بر روی محیط عملیاتی مستقر کنیم. همه‌ این تکنیک‌ها در کتاب تحویل مستمر گرد آمدند.

فکر می‌کنم آنچه باعث موفقیت آن شد این بود که افرادی که بر روی سیستم‌های تحت وبِ با مقیاس بزرگ کار می‌کنند، همه همزمان با هم از تکنیک‌های کاملاً مشابهی استفاده می‌کردند. وقتی ما کتاب را می‌نوشتیم، تیم فیتس درباره تحویل مستمر در شرکت IMUV (همان شرکتی که اریک ریس از بنیانگذارانش بوده) یک پست در وبلاگش گذاشت که البته آنجا، این مسأله طوفان عظیمی ایجاد کرده بود زیرا آنها هر روز چندین بار سیستم عملیاتی را مستقر می‌کردند.

در همان زمان افرادی مانند جان آلسپو و پل هاموند در کنفرانس Velocity در سال ۲۰۰۹، آن ارائه با عنوان ۱۰ بار تحویل دادن در روز را داشتند. بعد از آن بود که موارد مرتبط با پردازش ابری و DevOps مطرح شد. بنابراین فکر می‌کنم در یک زمان، افراد مختلفی بودند که به تکنیک‌های مشابهی رسیدند که به تحویل مستمر انجامید. اما اساساً تحویل مستمر همه‌اش در این باره است که فرآیند تحویل نرم‌افزار را طوری تغییر دهیم که اقتصادی شده و در تکه‌های کوچک انجام شود. علتی که ما حتی در بسترهای چابک (agile)، این سبک‌های خیلی آبشاری را داریم این است که فرآیندی که از آغاز پروژه آغاز می‌شود و بعد مراحل تأیید، تخصیص بودجه، نیازسنجی، توسعه، یکپارچه‌سازی و بعد نسخه دادن را طی می‌کند، هنوز فرآیند خیلی پرهزینه‌ای است و اقتصادی نیست که آن را در گام‌ها و تکرارهای کوچک انجام دهید. در واقع آنچه تحویل مستمر انجام می‌دهد این است که اقتصاد آن را تغییر می‌دهد و می‌توانید بر روی تکه‌های کوچک کار کنید و تغییرات کوچکی را از آن طریق انجام دهید.

آیا شما این کار را با خودکارسازی همه‌ چیز از آغاز تا انتها و از پذیرش تا تحویل انجام می‌دهید؟

این، یک بخش آن است؛ این‌که یک فرآیند خودکار از پذیرش تا نسخه دادن داشته باشید. فکر می‌کنم بخش دیگر آن معماری است و بخش دیگر، مدیریت پیکربندی (configuration management) است. اینکه اطمینان یابید که هر چه برای بازسازی محیط عملیاتی نیاز دارید، در مخزن کنترل نسخ (version control) قرار گرفته است. همین‌طور برای اینکه بتوانیم آن را به‌صورت مؤثر انجام دهیم مجموعه‌ای از رویه‌ها مانند یکپارچه‌سازی مستمر (continuous integration) وجود دارد که باید از آنها پیروی شود.

قبل از آنکه درباره مباحث مدیریت پیکربندی و یکپارچه‌سازی مستمر عمیق‌تر شویم آیا ممکن است یک مثال موفق از پروژه‌هایی بزنید که به روش تحویل مستمر انجام داده‌اید تا برایمان ملموس‌تر شود.

بله، پروژه ISP یکی از آنهاست. افراد این‌طور فکر می‌کنند که تحویل مستمر مربوط به نرم‌افزارهای تحت وب است اما این‌طور نیست. من مدیر محصول یک ابزار متن‌باز با نام GoCD بودم که یک ابزار برای تحویل مستمر است و یک بسته‌ نرم‌افزاری است (تحت وب نیست) اما آنجا ما تحویل مستمر را پیاده‌سازی کردیم به این معنا که هر تغییری باعث می‌شد که بسته‌ محصول دوباره تولید شود و بعد تست‌های خودکار را اجرا می‌کردیم و بعد برنامه‌های نصب مختلف برای سولاریس، ویندوز، مک او.اس و لینوکس را می‌ساختیم و بعد تست‌های عملیاتی را انجام می‌دادیم. در واقع ما خط تولید استقرار (deployment pipeline) را داشتیم که برنامه‌های نصب مختلف را تولید می‌کرد و کپی‌هایی از انواع محیط‌های عملیاتی مربوط به مشتری‌های مختلف را داشتیم و برنامه‌های نصب در آن محیط‌ها اجرا می‌شد تا عملیات ارتقا (upgrade) انجام شود و مطمئن شویم که فرآیند عملیاتی کردن با برنامه‌های نصب درست کار می‌کند. بنابراین این روش برای بسته‌های نرم‌افزاری هم بسیار خوب بود و خیلی مؤثر بود زیرا نسخه‌ دادن در این حد ساده شده بود که فقط برنامه‌های نصب را در وب‌سایت بارگذاری کنیم.

مثال دیگری که واقعاً برایم جالب است و به‌شخصه در آن دخیل بودم، مربوط به کاری است که در HP انجام شد. کتابی با عنوان رهیافتی عمل‌گرا به توسعه چابک بزرگ‌مقیاس (A Practical Approach to Large-Scale Agile Development) نوشته گری گروور هست که درباره فِرم‌ویر پرینتر لیزرجت HP است و درباره‌ این است که چگونه برای فرم‌ویر لیزرجت HP، سیستم تحویل مستمر راه انداختند. معمولاً افراد فرم‌ویرشان را ۱۰ بار در روز بروز نمی‌کنند. چنین چیزی را خیلی مشاهده نمی‌کنید :-) با این‌ حال آنها تحویل مستمر را راه انداختند تا تست‌های خودکار کاملاً جامعی داشته باشند. یک تیم خیلی بزرگ بر روی آن کار می‌کردند، یک تیم ۴۰۰ نفره‌ پراکنده در ۳ کشور، بر روی مخازن کد داخلی‌شان کار می‌کردند و می‌توانستند روزانه ۴۰۰ تغییر را (به مخزن اصلی) بفرستند. صدها هزار خط کد، هرروزه تغییر می‌کرد. آنها تقریباً هر روز ۱۰ بار بیلد می‌کردند که بر روی آنها مجموعه تست‌های خودکار گسترده‌ای انجام می‌شد و ظرف یک روز یک بازخورد کامل از کیفیت کار دریافت می‌کردند و مطمئن می‌شدند که همه خطاهایی که پیدا شده بود را برطرف کرد‌ه‌اند. بنابراین نرم‌افزار همواره در یک وضعیت قابل نسخه‌دهی قرار داشت. این تفاوت چشم‌گیری در اقتصاد فرآیند ایجاد کرد. آنها توانستند از لحاظ مدت زمانی که تیم برای توسعه ویژگی جدید و یا برطرف کردن خطاها داشت، نسبت به زمانی که تست‌های دستی انجام می‌دادند یا کدهای از انشعاب‌های مختلف را ادغام می‌کردند، ۸ برابر کاراتر شوند. خیلی از فعالیت‌های بی‌ارزش از بین رفت و از آنجایی که آنها یک فاز یکپارچه‌سازی و مرتب‌سازی داشتند می‌توانستند یک ویژگی جدید را در اواخر کار توسعه، انجام دهند، یعنی نسبت به زمانی که قبلاً یک ویژگی باید ثابت (freeze) می‌شد، اکنون می‌توانستند همچنان تغییر داشته باشند و این، نوعِ ارتباطشان با بازار و فروش را نیز تغییر داد.

از صحبت‌های شما، به نظر می‌رسد که تحویل مستمر، مزایای زیادی برای کسب و کار دارد اما به‌عنوان یک توسعه‌دهنده، چه چیزی برای من دارد؟ البته به‌غیر از اینکه واضح است که کسب و کار است که هزینه من را می‌دهد.

سئوال خوبی است. فکر می‌کنم در تحویل مستمر چیزهای زیادی باشد که توسعه‌دهندگان دوستش نداشته باشند. یکی از مقاله‌های مورد علاقه من درباره تحویل مستمر، مطلبی است که استیو یگ نوشته است البته این مطلب در اصل در مورد تحویل مستمر نیست اما به آن هم اشاره پیدا می‌کند. او در این مورد نوشته که چرا گوگل، سکوی کار (platform) را مشابه با آمازون، نمی‌فهمد. یکی از چیزهایی که در مورد آن صحبت کرده این است که چگونه برخی کارها برای توسعه‌دهندگان در آمازون دردآور است. کارهایی از قبیل اینکه مطمئن شوند کدها در محیط عملیاتی کار خواهند کرد، و بتوانند آن را (در محیط عملیاتی) مانیتور کنند و متوجه عملکردش بشوند. انجام این کارها که اغلب مهندسان، آن را بخشی از شغل خود نمی‌دانند برایشان سخت است. بنابراین باید کارهایی را به جز سروکله زدن با کد انجام دهند که خیلی آزاردهنده است. این از روش وارنر ووگل، مدیر ارشد فنی آمازون برآمده است. او گفته‌ای دارد که «شما می‌سازیدش، شما هم اجرایش می‌کنید.» بنابراین همان افرادی که مسئول ساختن نرم‌افزار هستند، همان‌ها هم آن را در محیط عملیاتی راه می‌اندازند. بنابراین باید یاد بگیرید که چطور این کار را بکنید. این یک تغییر فرهنگی بزرگ برای توسعه‌دهندگان است اما در عین حال بازخورد خیلی مهمی هم ایجاد می‌کند زیرا به این معناست که توسعه‌دهندگان باید معنای کدهای آماده به عملیات را بدانند نه این‌که فقط معنای تمام شدن توسعه کد را بدانند. خیلی مهم است که توسعه‌دهندگان این مفهوم را متوجه شوند زیرا وقتی می‌خواهند کد را توسعه دهند باید چیزهای زیادی را در ذهن داشته باشند و نگرانش باشند مثلاً چیزهایی از قبیل مقیاس‌پذیری، دسترس‌پذیری، نوشتن پیام‌های لاگی که بکار آید و فقط صفحات متوالی از خطاهای اشاره‌گر تهی (null pointer) نباشد و مسائل دیگری از قبیل آرشیو‌ کردن داده‌ها. در غیر این صورت، نمی‌توانید آن چرخه بازخورد را بسازید تا بفهمید که چه چیز از نرم‌افزاری که ساخته‌اید در محیط عملیاتی عمل نکرده است. یادگیری این چیزها برای توسعه‌دهنده‌ها خیلی سخت است و می‌تواند برای آنها خیلی آزاردهنده باشد.

مورد دیگر که یک تغییر فرهنگی برای توسعه‌دهندگان به حساب می‌آید این است که هنگامی که بر روی پیاده‌سازی ویژگی‌های بزرگ کار می‌کنند آنها را به گام‌های افزایشی کوچک بشکنند که بتواند قابل تحویل باشد یعنی حتی اگر پیاده‌سازی ویژگی پایان نیافته، به جای اینکه در یک انشعاب (branch) مربوط به ویژ‌گی‌های جدید قرار بگیرد، بتواند در شاخه اصلی (trunk) قرار بگیرد که قرار است تحویل شود. این هم یک تغییر فرهنگی بزرگ برای توسعه‌دهندگان است زیرا باعث کند شدن آنها می‌شود چراکه اگر قرار باشد از ابتدا تا انتهای کار، در گام‌های کوچک افزایشی انجام شود، بیشتر طول می‌کشد تا اینکه کار در یک انشعاب مربوط به ویژگی جدید انجام شود.

اما فکر می‌کنم آنچه واقعاً خوب است این است که شما به‌عنوان توسعه‌دهنده، می‌توانید یک ایده دریافت کنید، آن را به محیط عملیاتی ببرید و بلافاصله تأثیر آن را ببینید؛ به این ترتیب، چرخه‌ بازخورد خیلی سریعی خواهید داشت. کاری را انجام می‌دهید و حتی ممکن است بتوانید در همان روز و قطعاً در همان هفته، تعامل افراد با آن کد را ببینید. در عوض، در مدل سنتی باید هفته‌ها بلکه ماه‌ها منتظر می‌شدید تا نرم‌افزار در محیط عملیاتی اجرا شود و حتی ممکن بود شما از پروژه رفته باشید و کار را به کس دیگری سپرده باشید. بنابراین در این شرایط هیچ‌گاه کار کردن افراد با آن را نمی‌دیدید. برای توسعه‌دهندگان چنین چیزی خیلی تیره‌بختی است. در واقع اینکه بتوانید کار را به محیط ببرید و استفاده کردن افراد و بازخورد آن را ببینید، خیلی خوب است. من فکر می‌کنم این خیلی خیلی ارزشمند است.

آیا از زمانی که به گفته خود به مشتری و کاربران نزدیک‌تر شده‌اید، رهیافت توسعه نرم‌افزارتان تغییر کرده است؟

جالب است زیرا من هیچ‌گاه، واقعاً روش بد آن را تجربه نکرده‌ام. بعد از فارغ‌التحصیل شدن از کالج، اولین تجربه‌ام کار در یک استارتاپ در لندن بود. می‌توانم به طنز بگویم که آنجا ما تحویل مستمر و حتی استقرار مستمر (continuous deployment) داشتیم زیرا ما فایل‌ها را مستقیماً با ftp از ایستگاه‌ها (workstation) به محیط عملیاتی می‌فرستادیم. در سال ۲۰۰۰ ما حتی از مخزن کنترل نسخ (version control) استفاده نمی‌کردیم. فقط من بودم و فردی که مدیر ارشد فنی به حساب می‌آمد و فقط از ftp استفاده می‌کردیم. البته قطعاً این روشی نیست که بخواهم الان آن را توصیه کنم. بعد از آن پیشرفت کردم و در پروژه‌های بزرگ کار کردم که در آنجا بود که با این مشکلاتی که در موردش صحبت کردیم برخوردم.

از آنجایی که اولین تجربه من، کار در یک محیط استقرار مستمر بود قطعاً درد نداشتن تحویل مستمر را حس می‌کردم، اینکه هفته‌ها کد را شخم بزنید اما هیچ نسخه‌ای منتشر نشود. وقتی نمی‌توانید ببینید که مزایای کار چه بوده است این درد دو چندان می‌شود. فکر می‌کنم این مشکل عمومی توسعه‌دهنده‌ها است.

من قبل از آنکه به شرکت ThoughtWorks بپیوندم هیچ نوعی از TDD را تجربه نکرده بودم. آن زمان بود که به تیمی پیوستم که همه به این روش کار می‌کردند. آن موقع بود که شستشوی مغزی شدم و از آن به بعد همین روش را ادامه دادم و عاشقش هستم، من دیگر هیچ‌گاه به روش دیگری کار نخواهم کرد. من این تجربه تغییر مسیر دادن را داشته‌ام. به خاطر دارم که وقتی کتاب XP آمد، آن را خواندم و گفتم این هیچ وقت جواب نمی‌دهد. بعد وقتی برای کار به ThoughtWorks رفتم، افرادی را دیدم که TDD کار می‌کردند و نرم‌افزار را دقیقاً به همین روش تولید می‌کردند. آن موقع با خودم گفتم: خدای من! نه تنها جواب می‌دهد بلکه نسبت به هر روش دیگر توسعه نرم‌افزار، کلی هم جذاب‌تر است.

بنابراین فکر می‌کنم که خیلی دشوار است که بخواهیم با منطق کار کنیم و با استدلال‌های منطقی افراد را مجاب کنیم. تنها راهش این است که خودتان آن را امتحان کنید و با افرادی کار کنید که این روش کار را دوست دارند. البته حتی در این‌ صورت هم ماه‌ها طول می‌کشد تا یاد بگیرید که چطور آن را انجام دهید.

این نکته‌ خوبی بود.
با فرض اینکه یک وب‌سایت بزرگ چند میلیون کاربری داشته باشم، چطور باید راه‌اندازی تحویل مستمر را آغاز نمایم؟

سئوال خوب و البته سختی است زیرا چیزهای زیادی باید عوض شود. فقط فرآیند توسعه نرم‌افزار نیست بلکه در مورد نحوه تفکر شما در مورد مدیریت پروژه، حتی نحوه تفکر شما در مورد تخصیص بودجه و مدیریت ریسک هم هست. همه اینها باید تغییر کند. فکر می‌کنم تنها روشش این است که آن را گام‌به‌گام و افزایشی انجام دهید.

مورد خاصی که با آن شروع می‌کنید چیست؟

من برایتان مثالی از آمازون می‌زنم. آمازون یک تغییر معماری از یک معماری برآمده از مدل (model driven architecture) به یک معماری سرویس‌گرا (service oriented architecture) داشت. این کار ۴ سال طول کشید. آن‌ها از الگویی استفاده کردند که مارتین فاولر و دیگران زیاد در مورد آن در وبلاگ‌شان نوشته‌اند. این الگو، الگوی برنامه‌ خفه‌کننده (strangler application) نام دارد. عملاً معماری، بزرگ‌ترین یا یکی از بزرگترین موانع دستیابی به تحویل مستمر است. اگر مجبور باشید که همه چیز سیستم را با هم به روش انفجار بزرگ (big bang) تحویل دهید، خیلی سخت است که به مزایای آن برسید.

بنابراین آنچه آمازون انجام داد این بود که تغییر معماری به یک معماری سرویس‌گرا داشتند اما این کار را گام‌به‌گام انجام دادند. آنها یک سرویس خاص را برمی‌داشتند و آن را مجدداً پیاده‌سازی می‌کردند و در طی زمان، به تدریج سرویس‌های بیشتری برداشته شده بود.

در مورد برنامه خفه‌کننده، تشبیهی که می‌شود این است که مانند جنگل‌های انبوه استوایی است که درختان زیادی وجود دارد و بعد یک درخت تاک پهن، دور درخت دیگری را می‌گیرد و به تدریج آن را دربرگرفته و خفه می‌کند. این همان روشی است که ما به تدریج یک معماری را بنا می‌کنیم. ما به تدریج سرویس‌هایی را جدا می‌کنیم و در نهایت برنامه یکپارچه (monolithic) را خفه می‌کنیم.

فکر می‌کنم کار واقعاً هوشمندانه‌ای که آمازون انجام داد این بود که این‌ کار را با تغییرات سازمانی ترکیب کرد. یعنی همان تغییر که: «شما می‌سازیدش، شما هم اجرایش می‌کنید.» این ایده که برای هر سرویس تیمی داشتند که مسئول آن سرویس در تمامی چرخه زندگی‌اش (life cycle) بود. همین‌طور، ایده‌ تیم‌های دو پیتزایی را مطرح کردند: «نباید تیمی باشد که نتوان آن را با دو پیتزا تغذیه کرد»، که تقریباً معادل ۱۰ نفر است. و آن تیم مسئول آن سرویس در تمامی طول چرخه زندگی‌اش بود. این بر روی اندازه سرویس تأثیر داشت که همان معماری ریزسرویس‌ها را تعریف می‌کند که بحث‌هایی درباره‌اش هست و آمازون از پیشگامانش است. یکی از کارهای هوشمندانه‌ای که آمازون کرد، به خدمت گرفتن قانون کانوِی بود. قانون کانوی می‌گوید معماری سیستم، انعکاس یافته از ساختار ارتباطات سازمان است و یا معماری براساس ساختار ارتباطات سازمانی که آن معماری را می‌سازد، شکل می‌گیرد.

بنابراین با گفتن اینکه می‌خواهید معماری سرویس‌گرا داشته باشید و می‌خواهید برای هر سرویس یک تیم داشته باشید، یک حرکت هوشمندانه ایجاد شد. آنها یک تیم تکاورهای مخصوص استخدام کردند که وظیفه‌شان این بود که به همه تیم‌ها سر بزنند و اطمینان یابند که تیم‌ها با پایگاه داده تیم‌های دیگر صحبت نمی‌کنند! آنها اگر متوجه می‌شدند که دارید بدون واسطه لایه سرویس با پایگاه داده یک تیم دیگر صحبت می‌کنید، دخلتان را می‌آوردند و اگر تلاش می‌کردید که به این‌کار ادامه دهید، اخراج می‌شدید.

اگر به قانون کانوِی برگردیم، آنچه شما می‌گویید این است که با دادن مسئولیت به افراد تیم توسعه -طوری‌ که در کنار تیم کسب و کار در قبال عملیات (operations)، مسئول باشند- نیاز به تحویل مستمر را ایجاد می‌کنید. زیرا وقتی افراد کنار یکدیگر می‌نشینند و با یکدیگر کار می‌کنند و رئیس یکسانی دارند، شروع می‌کنند که با همدیگر تحویل دادن، را آغاز کنند که به تحویل مستمر می‌انجامد.

درست است. و همین‌طور معماری [هم هست] زیرا معماری یک جزء کلیدی است. با ایده اقتصادی کردن کار با داشتن بسته‌های کوچک تغییرات که قبلاً بیان شد، بخش معماری کار را ایجاد می‌کنید و با داشتن نوعی ساختار تیمی که در آن افراد می‌توانند تغییرات را خودشان در محیط عملیاتی اعمال کنند (که نیازی ندارید که از خلال یک فرآیند مدیریت تغییرات متمرکز، این کار را انجام دهید و می‌توانید تغییرات را داخل تیم خودتان اعمال کنید)، بخش سازمانی کار را انجام می‌دهید. بنابراین، بله، به این ترتیب بخش معماری و بخش سازمانی را دارید که با هم همراستا شده‌اند.

بیایید موضوع را مقداری عوض کنیم و در مورد فرآیند تحویل مستمر عمیق‌تر شویم. شما در کتاب‌تان گفته‌اید که نسخه دادن نباید ترسناک باشد. چرا امروزه نسخه دادن ترسناک است؟

فکر می‌کنم به چند دلیل، ترسناک است. اول اینکه در خیلی از سازمان‌ها، نرم‌افزارشان را برای تحویل مستمر معماری‌ نکرده‌اند و این به نسخه رسیدن، کاری طاقت‌فرساست. قطعاً برخی افراد که به این مصاحبه گوش می‌دهند، نسخه را در خارج از ساعت اداری منتشر می‌کنند (شب‌ها، تعطیلات آخر هفته و ...) و این کاری است که چند ساعت به طول می‌انجامد. فکر می‌کنم دو معیار وجود دارد. یک معیار تعداد ساعاتی است که خارج از وقت معمول اداری برای فراهم کردن نسخه سپری می‌کنید و دیگری، تعداد خطاهایی است که باید بعد از آن به صورت اورژانسی برطرف شود. این‌ها دو معیار مفید هستند.

چیز دیگری که ترسناک است این است که آیا این ویژگی‌ها برای کسب و کار یا مشتری‌ها ارزشی ایجاد کرده است یا خیر؟ در این زمینه رونی کاهاوی مقاله خیلی خوبی دارد. او از کسانی بود که چارچوب تست A/B را در آمازون راه انداخت و بعداً به مایکروسافت رفت و سکوی (platform) آزمایشی خود (بینگ) را راه انداختند. او داده‌هایی از تست A/B دارد که نشان می‌دهد که دو سوم از ویژگی‌هایی که افراد فکر می‌کنند ایده‌های خیلی خوبی است برای مشتری‌‌ها ارزش صفر یا منفی ایجاد می‌کند. اگر این داده‌ها را عمومیت دهید به این معناست که دو سوم ویژگی‌هایی که ما می‌سازیم و فکر می‌کنیم ارزش دارند، برای مشتری‌ها ارزش صفر یا منفی ایجاد می‌کنند. این باید ترسناک باشد. و اگر شما بر روی نسخه‌های ۳ ماهه کار کنید، چگونه می‌خواهید محاسبه کنید که کدام‌یک از این ویژگی‌ها باعث افزایش یا کاهش معیارهای کسب و کاری که به آنها توجه دارید -مثلاً سود حاصل شده از هر مشتری- شده‌اند؟

چون خیلی چیزها تغییر کرده‌اند...

بله، چیزهای زیادی تغییر کرده‌اند و حالا چطور می‌خواهید ردیابی کنید که کدام‌یک از کارهایی که انجام داده‌اید واقعاً ارزش‌آفرین بوده‌اند. جاشوآ کریوفسکی می‌گوید شما باید بتوانید به هر خط از کد یک ارزش دلاری انتساب دهید. اگر نمی‌توانیم این کار را بکنیم، لااقل باید بتوانیم با (نسخه دادن در) بسته‌های کوچک و تست‌های A/B بفهمیم که کدام ویژگی‌ها واقعاً ارزش ایجاد کرده‌اند.

چرا خودکار کردن نسخه‌دهی و انجام بیشتر آن‌ها، کمتر ترسناک باشد؟

سئوال خوبی است. این غیرمنطقی به نظر می‌رسد. اگر تحویل دادن دردآور است، بیشتر انجام دادن آن احمقانه به نظر می‌رسد.

باعث درد بیشتر می‌شود...

بله، به نظر می‌رسد دردآورتر می‌شود. اما نکته این است که چیز کمتری را تحویل می‌دهید. به چند دلیل (کار ساده‌تر می‌شود). اول اینکه، آن را بیشتر تجربه می‌کنید و این می‌تواند شما را مجبور به ساده‌سازی کند. آنچه ناچار است با خودکارسازی، همراه شود، ساده‌سازی است. اگر یک فرآیند دستی زجرآور را بردارید و همان را خودکار کنید، به یک فرآیند زجرآور شکننده خودکار می‌رسید که واقعاً بهبودی حاصل نمی‌شود. بلکه باید معماری فرآیند خود را طوری سازماندهی مجدد کنید تا تحویلش ساده شود که مربوط به بخش معماری کار است. بنابراین ساده‌سازی هم همراه با خودکارسازی می‌آید و این باعث کاهش مقداری از ریسک‌ها می‌شود. مرتب نسخه دادن نیز مقداری از ریسک‌ها را می‌کاهد. همین‌طور از آنجایی‌که چیزهای کمتری در هر نسخه تغییر می‌کند، اگر چیزی اشتباه باشد، پیدا کردن آن و برطرف کردنش خیلی ساده‌تر خواهد بود چون توجه دارید که ما نمی‌گوییم که ۳ ماه کار کنید و آن را ۱۰ بار در روز منتشر کنید بلکه می‌گوییم به‌قدر یک دهم روز کار کنید و آن را ۱۰ بار در روز منتشر کنید که می‌تواند تغییر در یک خط کد یا تغییری در یکپارچه‌سازی‌ها باشد.

من می‌خواهم در اینجا به اصطلاح رفع‌خطای به جلو (fix-forward) اشاره کنم. آیا ممکن است در مورد آن توضیح بیشتری بدهید.

این چیزی است که در سازمان‌های کارآمد می‌بینیم و مدت‌هاست که آن را اجرا می‌کنند. آنها هیچ‌گاه عقب‌گرد نمی‌کنند و همواره اگر مشکلی پیدا شود رو به جلو حرکت می‌کنند. یکی از تکنیک‌هایی که ما در کتاب توضیح داده‌ایم استقرار سبز/آبی (blue/green deployment) است. استقرار سبز/آبی این ایده است که شما اساساً دو نسخه از محصول عملیاتی را دارید که یکی از آنها زنده (در حال اجرا) است و دیگری زنده نیست که می‌توانید آن را نسخه صحنه (Staging) بنامید. کاری که انجام می‌دهید این است که (نسخه را) در محیط صحنه، مستقر می‌کنید و مسیریاب (router) یا DNS یا ترازگر بار (load balancer) را تنظیم می‌کنید که به محیط صحنه مسیردهی کند تا صحنه، زنده شود و آنچه قبلاً زنده بوده، تبدیل به صحنه شود.

این همان چیزی است که Netflix هم در مورد آن صحبت کرده است و به آن استقرار قرمز/سیاه می‌گوید. در واقع آنچه انجام می‌دهند این است که (نسخه را) بر روی صحنه، استقرار می‌دهند و به آرامی، کاربران را از نسخه زنده به نسخه صحنه، مهاجرت می‌دهند. و من فکر می‌کنم در حال حاضر اروپا محیط صحنه آن‌ها است :-) اگر در جریان استقرار به مشکلی بخورند، دوباره به نسخه‌ای که قبلاً زنده بود جابجا می‌شوند در نتیجه هیچ‌گاه نیاز به عقب‌گرد ندارند. آنها فقط نسخه جدید را در محیط صحنه مستقر می‌کنند و به تدریج کاربران را به آن مهاجرت می‌دهند و عقب‌گرد فقط به این معناست که کاربران به نسخه زنده اصلی برگشت داده شوند.

سازمان‌هایی که این کار را می‌کنند فقط رو به جلو حرکت می‌کنند. به عنوان مثال از دایان مارش که مدیر ابزارهای مهندسی در Netflix است، پرسیده شد که آیا شما اصلاً نسخه‌های ساخته شده [قبل] خود را نگه می‌دارید؟ و او گفت هرچند ما آن‌ها را در جایی نگهداری می‌کنیم، اما هیچ‌گاه به عقب برنخواهیم گشت و هیچ‌گاه نیاز نداریم که آن‌ها را دوباره تحویل دهیم.

آیا این به آن معنی است که از آنجایی‌ که من بیشتر تحویل دارم، سریع‌تر هم می‌توانم خطاهایی که از زیر دستم در رفته را برطرف کنم؟

بله، زیرا تغییر تنظیمات یک مسیریاب (router) نسبت به یک بازگشت به عقب کامل و مستقر کردن دوباره نسخه قبلی سریع‌تر است. و همین‌طور این رویه‌ای نیست که ما زیاد تستش کرده باشیم. مستقر کردن در محیط عملیاتی با مستقر کردن در صحنه‌‌ها مثلاً محیط تست متفاوت است زیرا باید نگران داده‌ها در محصول عملیاتی باشید. اغلب بازگشت به عقب، شامل تغییر در داده‌ها هم هست که واقعاً فرآیند پرخطری است و چیزی نیست که افراد خیلی زیاد آن را تست کرده باشند. بنابراین بازگشت به عقب می‌تواند خیلی خیلی خطر داشته باشد.

شما چندین بار به تست A/B اشاره داشتید. ممکن است به اختصار توضیح دهید تست A/B چیست و چرا در تحویل مستمر اهمیت دارد؟

قطعاً. تست A/B در واقع از تجارت ارسال نامه می‌آید. افرادی که نامه‌های تبلیغاتی به صندوق‌های نامه واقعی و فیزیکی می‌فرستادند، نسخه‌های مختلفی از آن تبلیغات را به افراد مختلف می‌فرستادند و می‌دیدند که کدام‌یک از آن نسخه‌های تبلیغاتی، نرخ پاسخ بیشتری داشته است.

اما این را در نرم‌افزار به چه شکل خواهید دید؟ به این‌صورت خواهد بود که دو نسخه مختلف از یک صفحه خواهید داشت؛ به برخی از کاربران یک نسخه و به بقیه نسخه دیگر را نمایش می‌دهید و باید آنها را در تمام مدت جلسه (session) ردیابی کنید. در این‌جا آنچه می‌سازید دسته (cohort) نام دارد که دسته‌ای از کاربران هستند که تقریباً در یک زمان به وب‌سایت وارد می‌شوند و شما جلو رفتن آنها در وب‌سایت را ردیابی می‌کنید که این ردیابی شامل این هم می‌شود که آیا نسخه A یا نسخه B از یک صفحه خاص را دیده‌اند؛ بعد در انتهای این گشت‌وگذار، می‌بینید که کدام‌یک از آنها، رفتار مطلوب را داشته‌اند مثلاً در مورد وب‌سایت آمازون این رفتار مطلوب می‌تواند این باشد که آخرسر چه مقدار خرید داشته‌اند.

یک پی‌آمد اصلی برایش تعریف می‌کنید...

بله، این نتیجه ارزیابی کلی آزمایش نامیده می‌شود و باید در طی زمان، انبوهی از این داده‌ها را جمع کنید تا بتوانید اطلاعات آماری مهم را تولید کنید. بنابراین در طی زمان این داده‌ها را از دسته‌های مختلف جمع می‌کنید تا بفهمید کدام صفحه، پی‌آمد درست را داشته است. در آمازون یا بینگ و ... چندین تست A/B مختلف در نسخه عملیاتی دارند. ده‌ها و در برخی شرایط صدها تست A/B در جریان است اما آنها کاملاً بادقت بررسی می‌کنند که هر دسته کاربران، کدام‌یک از این ترکیب‌ها را مشاهده کرده است زیرا روشن است که نمی‌خواهید تست‌ها با هم تداخل پیدا کنند.

بله، تست‌های چند متغیره، زجرآور است.

درست است.

بیایید تمرکزمان را از اینکه چرا آن را انجام می‌دهیم به این معطوف کنیم که چگونه سازمان‌‌مان و فرهنگ سازمانی‌مان باید تغییر یابد. شما در کتاب گفته‌اید که تحویل مستمر از روش تَرکه‌ای (lean) نشأت می‌گیرد. آیا ممکن است توضیح دهید که منظورتان چیست؟

اگر به سال‌های ۲۰۰۴ و ۲۰۰۵ برگردیم، آن زمان من کتاب مری پاپندیک و تام پاپندیک با عنوان توسعه نرم‌افزار به روش ترکه‌ای را خوانده بودم که انقلاب بزرگی بود. وقتی من به‌همراه دِیو کتاب تحویل مستمر را می‌نوشتیم مجموعه نوشتارهای دیگری هم درباره روش تَرکه‌ای خواندیم و به این نتیجه رسیدم که خیلی از ایده‌ها (در تحویل مستمر) ریشه در فلسفه تَرکه‌ای دارد.

یکی از آن ایده‌ها که از فلسفه تَرکه‌ای آمده است و دوست دارم درباره‌اش صحبت کنم جیدوکا (Jidoka) است که در واقع مفهومی است که در سال ۱۹۹۴ توسط یکی از افراد خانواده تویوتا که فکر می‌کنم ساکیچی تویودا باشد، ابداع شد. تویوتا قبل از اینکه به سراغ خودرو برود، بر روی ماشین‌های بافندگی کار می‌کرد. در آن زمان، محصولی با نام ماشین بافندگی خودکار نوع G را عرضه کردند که یک ویژگی نوآورانه داشت که می‌توانست اگر مشکلی در فرآیند بافندگی روی داده باشد مثلاً اگر نخ پاره شده باشد یا نخ ماسوره تمام شده باشد، شناسایی کرده و به‌طور خودکار متوقف شود.

چیزی مشابه با یکپارچه‌سازی مستمر (continuous integration) این روزها.

دقیقاً. درست است، آن هم همین رویه را دارد که اگر مشکلی وجود داشت همان وقت آن را بفهمید. در مورد ماشین‌های بافندگی، آنچه به ارمغان آورد این بود که به جای این‌که هر ماشین بافندگی یک اپراتور داشته باشد، می‌توانستند یک اتاق پر از ماشین‌های بافندگی داشته باشند که فقط یک اپراتور داشته باشد زیرا ماشین به شما می‌گفت که اتفاق بدی افتاده است. همان‌طور که شما اشاره کردید این همان چیزی است که در یکپارچه‌سازی مستمر هم داریم.

یک فرآیند مشابه دیگر که داریم این است که به‌جای داشتن تستر‌هایی که به‌صورت دستی، نرم افزار را تست کنند، تست‌های خودکاری داشته باشید که اگر پَسرفت عملکرد جدی وجود داشت همان موقع آن را بفهمند و بتوانید همان موقع کار را متوقف کرده و مشکل را برطرف کنید. این ایده که کیفیت را در داخل خودِ کار بسازیم، فرآیند توسعه نرم‌افزار را خیلی کاراتر می‌کند. این همان ایده‌ای است که دمینگ در جنبش اجتماعی افزایش کیفیت در مورد آن صحبت کرده است. خیلی از ایده‌ها از جمله همین ایده از فلسفه تَرکه‌ای می‌آید.

مسئله دیگری که در کتاب در ارتباط با فرهنگ به آن اشاره کرده‌اید ایده کاهش زمان چرخه (cycle time) است. در اینجا چرخه به چه معناست؟

این سئوال خوبی است. دوباره اگر پیام تَرکه‌ای را درنظر آوریم، تعریف کردن زمان چرخه خیلی ساده است زیرا می‌توانید به سادگی، حرکت فیزیکی تولیدات در کارخانه را ببینید. می‌توانید خودروها را ببینید که وارد خط تولید می‌شوند. در نرم‌افزار، لمس این تولیدات خیلی سخت‌‌تر است.

ما تعداد زیادی چرخه داریم. تکرار‌ها (iteration) را داریم و ...

بله، ما ویژگی‌ها (feature) را داریم. اگر تولیدات ما ویژگی‌ها باشند، چگونه باید حرکت ویژگی‌ها را اندازه بگیریم؟ نقطه شروع یک ویژگی چیست؟ آیا آن زمانی است که از ابتدا ایده‌اش را دارید؟ آیا زمانی است که آن ایده را در یک سیستم ردگیری (tracking system) یا بر روی یک کارت ثبت می‌کنید؟ یا زمانی است که آن را بر روی انباره (backlog) اولویت‌بندی شده خود می‌آورید؟ چه زمانی دکمه شروع را می‌زنید؟

بله، چه زمانی دکمه شروع و چه زمانی دکمه پایان را می‌زنید؟

فکر می‌کنم به‌شکل خاص در مورد تحویل مستمر، یکی از وضعیت‌هایی که خیلی قابل مشاهده واقعی باشد، زمانی است که آن را در مخزن کنترل نسخ (version control) وارد می‌کنید. این تعریف، در واقع تمامی چرخه نیست و باید به این دقت کنیم که روند ایده‌سازی و تحلیل را نادیده نگیریم اما اگر چرخه را از زمان قرار گرفتن در مخزن کنترل نسخ تا زمان قرار گرفتن در سیستم عملیاتی تعریف کنیم، می‌توان به صورت قطعی آن را اندازه‌گیری کرد. در این‌صورت در قیاس خط تولیدی که در کتاب تحویل مستمر برای نرم‌افزار به‌کار رفته است، فرآیندی است که شما تغییری را در سیستم کنترل نسخ وارد می‌کنید و بعد تست‌‌ها را بر روی آن اجرا می‌کنید و بعد آنها را در بسته‌هایی قرار می‌دهید و به صورت خودکار در محیط عملیاتی مستقر می‌کنید یا بسته را برای کاربران، منتشر می‌کنید.

این همان چیزی است که آن را خط لوله استقرار (deployment pipeline) نامیده‌اید.

بله، خط لوله استقرار.

و آیا خط لوله استقرار باید حتما خودکار باشد؟ آیا ختما باید اسکریپت‌هایی داشته باشیم که این کارِ خط لوله استقرار را انجام دهند؟

بله، می‌توانید، هر چند که من فکر می‌کنم عموماً ارزیابی‌های دستی هم وجود دارد. در اغلب موارد نمی‌توانیم این‌قدر خوشبخت باشیم که نرم‌افزاری که تست‌های خودکار را قبول شده است را یک‌راست به محیط عملیاتی بفرستیم. شما می‌خواهید برخی تست‌های کاربری یا شاید تست‌های A/B داشته باشید. و نیز پیچیدگی‌هایی در مورد روانه کردن پنهان (dark launching) وجود دارد.

روانه کردن پنهان به چه معناست؟

این اصطلاحی است که فکر می‌کنم توسط فیسبوک ابداع شد و بوسیله Etsy پیشرفت کرد. به این معناست که کدی را در نسخه عملیاتی قرار می‌دهید اما آن بخش از کدها اجرا نمی‌شوند.

ویژگی‌ها را خاموش و روشن می‌کنید.

بله، ویژگی‌ها را خاموش و روشن می‌کنید یا این‌که آن را در بخشی از API قرار می‌دهید که هیچ چیزی در واسط کاربری به آن متصل نیست. این یک راه دیگر آن است. به عنوان مثال در Etsy اغلب تغییرات، به‌صورت پنهان وارد می‌شوند و بعداً به نوعی اتصالاتشان برقرار می‌شود. فیسبوک تکه نرم‌افزاری با عنوان محافظ خاکستری دارد که کنترل می‌کند که چه ویژگی‌هایی را بتوانید ببینید، می‌توانید یک ویژگی را انتخاب کرده و آن را تنها به یک جامعه خاص آماری نشان دهید یا آن را تنها به یک درصد از کاربران نمایش دهید که می‌تواند به منظور تست A/B باشد و یا در راه‌اندازی نهایی باشد و یا حتی برای مدیریت بار باشد، اگر بر روی یک ویژگی، حجم زیاد بار غیرعادی باشد، می‌توانید برخی ویژگی‌های پرهزینه را از مدار خارج کنید. این چیزی است که بسیاری از سازمان‌ها تجربه می‌کنند. بنابراین روانه کردن پنهان، برای اهداف مختلفی می‌تواند به‌کار آید.

من در اینباره مطلبی شنیده‌ام که این باعث مجزا شدن انتشار از استقرار می‌شود.

بله، این چیزی است که خیلی دوست دارم در مورد آن صحبت کنم. این را بعد از منتشر شدن کتاب واقعاً درک کردم.

شاید گفته شما باشد اما واقعاً نمی‌دانم کجا خواندمش.

من قطعاً دراین باره نوشته‌ام اما نمی‌دانم که آیا من شخصی هستم که این مفهوم را ابداع کرده یا خیر. ایده این است که استقرار به معنای ساختن و گذاشتن در محیط است اما انتشار، در دسترس قرار دادن ویژگی برای کاربران است. و این دو، اعمال کاملاً مستقلی است. اغلب ما آنها را به هم گره می‌زنیم و از طریق استقرار به انتشار می‌رسیم اما این‌کار خیلی پرخطر است. راه کم‌خطر این است که همه ویژگی‌ها را به‌صورت پنهان روانه استقرار کنیم، اما انتشار به معنای در دسترس قرار دادن ویژگی‌ها برای کاربران، روند خیلی آهسته‌تری داشته باشد و کاملاً مستقل از فرآیند استقرار باشد و به‌وسیله کسب و کار انجام ‌شود، با تست‌های A/B انجام ‌شود و با به‌آهستگی در مدار آوردن عملکردها انجام ‌شود.

و خاموش کردن آنها در صورت شکست خوردنشان...

بله، خاموش کردن آنها در صورت شکست خوردنشان و یا در صورتی که بار زیادی داشته باشند و چیزهای مشابه آن.

بخش مهمی از تحویل مستمر که هنوز در مورد آن صحبت نکرده‌ایم، بخش عملیات (operations) است. تحویل مستمر چه ارتباطی با DevOps و فرهنگ DevOps پیدا می‌کند؟

سئوال جالبی است زیرا در زمانی که کتاب را می‌نوشتم، جنبش DevOps داشت فراگیر می‌شد تا جایی که اصطلاح DevOps را در کتاب آوردیم و به خاطر دارم که مجموعه‌ای از مطالعات در زمینه DevOps انجام دادیم و در مورد آن با افراد صحبت می‌کردیم و خیلی در موردش علاقه‌مند شده بودیم.

اگر امروز می‌خواستید کتاب را نامگذاری کنید نامش را کتاب مقدس DevOps یا چنین چیزی می‌گذاشتید؟ :-)

نه، من واقعاً از عنوان کتاب راضیم و فکر می‌کنم درست باشد. اما DevOps قطعاً بخشی از آن محسوب می‌شود. فکر می‌کنم DevOps از جنبش WebOps می‌آید. در واقع کتابی که قبل از تحویل مستمر آمد، کتاب Web Operations بود.

عملیات وب (web operations) چیست؟ و چرا با DevOps متفاوت است؟

کتاب عملیات وب، توسط جان آلسپو و جسی روبینز نوشته شده است. در آن زمان، جسی روبینز پست ارشد در حوادث (master of disaster) در آمازون را داشت و جان آلسپاو در Flickr کار عملیات می‌کرد. این کتاب در واقع، نزدیک به همان چیزی است که باید باشد و شامل مجموعه‌ای کامل از مطالب مختلف از افرادی شامل انجی شیفر، اریک ریس و دسته‌ای از افراد دیگر است که الان خیلی شناخته شده هستند اما در آن زمان کمتر شناخته شده بودند. این کتاب در مورد نحوه ساختن سیستم‌های در مقیاس وب مانند فیسبوک و آمازون است. در اصل جنبش DevOps از اینجا نشأت گرفت.

سیستم‌های غیر از وب هم می‌توانند از چیزهای WebOps استفاده کنند؟

آنها [نویسندگان کتاب] به این چیزها اهمیتی نمی‌دادند. به ساخت بسته‌های نرم‌افزاری یا برنامه نصب اهمیت نمی‌دادند. آنها به‌شکل خالص، بر روی وب‌سایت‌های با حجم بالا تمرکز کردند و DevOps از آنجا آمد. آنها واقعاً به هیچ وجه بر روی هیچ حوزه دیگری تمرکز نمی‌کردند. در حالی‌ که فکر می‌کنم تحویل مستمر از پیش‌زمینه کاملاً متفاوتی آمد. ما فهمیدیم که خیلی از ایده‌های فلسفه تَرکه‌ای، خیلی از رویه‌ها و فرهنگ‌ها، همگی به یک چیز ختم شد. این چیزی است که برای ما خیلی جالب است و فکر می‌کنم به یک تغییر اساسی در نرم‌افزار انجامید. ما فهمیدیم که ایده‌های در زمینه فرهنگ‌ها و رویه‌ها که در حوزه‌های مختلف وجود دارد از تولید وب‌سایت‌های با مقیاس بالا گرفته تا تولید فرم‌ویرها و یا تولید بسته‌های نرم‌افزاری، ایده‌های یکسانی است. در واقع می‌توانید ایده‌های یکسانی را در این حوزه‌های مختلف به‌کار ببرید و نتایج واقعاً خوبی داشته باشید زیرا آنها اساساً به همان مقداری که در مورد یک رویه خاص بودند، به همان میزان، در مورد ساختن سازمان‌های پایدار و منعطف و تغییرات فرهنگی هم بودند.

یکی از چیزهایی که من را آزار می‌دهد این است که به جایی بروید و بگویید: «این چیزها خیلی خوب به نظر می‌رسد اما برای ما جواب نمی‌دهد زیرا ما فیسبوک نیستیم، ما سرویس‌های مالی ارائه می‌کنیم.»

که تا حدی درست است...

هم هست، هم نیست. مشکل این است که من دیده‌ام که این رویه‌ها در زمینه سرویس‌های مالی هم کار کرده است. من در سال ۲۰۱۴، به مدت ۴ هفته، برای یک بانک سرمایه‌گذاری کار کردم، ما در آنجا دسته‌ای از رویه‌هایی که در کتاب تحویل مستمر گفته شده بود را اجرا کردیم که خیلی مؤثر بود و تفاوت زیادی ایجاد کرد. من در سیستم‌هایی کار کرده‌ام که در آن صدها میلیون‌ دلار، مبادله اموال صورت می‌گیرد. در آنجا ریسک قابل توجهی وجود دارد اما ما این رویه‌ها را به کار می‌بریم زیرا آنها را واقعاً امن‌تر می‌کند.

مسئله این است که افراد می‌آیند و می‌گویند برای ما کار نمی‌کند. واقعاً؟! اینکه باعث افزایش کیفیت نرم‌افزار و پیدا شدن سریع‌تر خطاها می‌شود [کار نمی‌کند]؟! این چیزی است که به نظر من خیلی عجیب و غریب است که افراد می‌گویند برای ما کار نمی‌کند چون برایمان ریسک دارد. این رویه‌ها برای این طراحی شده‌اند که ریسک را کمتر کنند و کیفیت را افزایش دهند. بنابراین آنچه آن‌ها می‌گویند این است که ما نمی‌خواهیم آن را انجام دهیم و می‌خواهیم همان رویه‌های گاوچرانی خودمان را ادامه دهیم که در واقع کارها را خراب‌تر می‌کند!

من در تهیه گزارش وضعیت DevOps سال ۲۰۱۴ دخالت داشتم. یکی از چیزهایی که دنبالش بودیم اندازه‌گیری کارایی IT بود که بررسی از لحاظ بازدهی (همان فراوانی نسخه دادن)، از لحاظ زمان به ثمر رسیدن تغییر (change lead time)، از لحاظ پایداری از نظر زمان بازراه‌انداری سرویس به‌هنگام خرابی و تنزل (time to restore service) ، همین‌طور از لحاظ نرخ شکست تغییرات (نرخی از تغییرات که بعد از استقرار، شکست می‌خورند و مجبور به برطرف کردن مشکل یا برگشت به عقب می‌شوید) بود.

واضح است که بسیاری از فرآیندهای سنگین مدیریت تغییرات مانند داشتن هیأت مشاور تغییرات (change advisory board) و ... که خیلی از شرکت‌های بزرگ استفاده می‌کنند، بازدهی را می‌کاهد اما آنچه ما متوجهش شدیم و نتایج خیلی غافلگیر‌کننده‌ای بود، این بود که باعث افزایش پایداری هم نمی‌شدند. ما افرادی که برای تغییرات، این‌گونه فرآیندهای سنگین را داشتند با سازمان‌هایی مقایسه کردیم که از بازبینی توسط همتا (pair review) استفاده می‌کردند و در آنها توسعه‌دهندگان کارهای همدیگر را یا از طریق یک فرآیند سبُک پذیرش تغییرات یا از طریق برنامه‌نویسی زوج (pair programming) بررسی می‌کردند. ما انتظار داشتیم (که فرآیندهای سبک‌تر) باعث کاهش پایداری شود اما در عین شگفتی متوجه شدیم که اصلاً این‌طور نیست و به‌همان میزان فرآیندهای سنگینِ مدیریت تغییرات، پایداری دارند.

بنابراین این ایده که این چیزها، برای ما کار نمی‌کند، غلط است. از لحاظ روانشاسانه، می‌توانم بفهمم چرا افراد این‌طور فکر می‌کنند. زیرا با خود می‌گویند ما و آمازون، مشکلات متفاوتی داریم، اما فراموش کرده‌اند که آن‌ها شرکت‌ ثبت‌شده‌ای هستند که PCI DSS دارند (PCI DSS مخفف Payment Card Industry Security Standards است که یک‌سری استانداردهای امنیتی است که سازمان‌های رسیدگی کننده به تراکنش‌های مالی مربوط به کارت‌های visa، master، american express و ... ملزم به رعایت آن هستند- مترجم). آن‌ها با آن حجم کاری، احتمالاً فرآیندی دارند که بیشترین تعداد اقدامات احتیاطی نسبت به هر شرکت دیگری در دنیا را دارند. بنابراین آن‌ها هم در معرض این مقررات هستند. خطایی که افراد در این سازمان‌های بزرگ می‌کنند این است که می‌خواهند برای همه یک نسخه بپیچند. آن‌ها می‌گویند که: این مقررات ماست و می‌خواهیم آن را در همه سیستم‌های مختلف‌مان بکار ببریم. اما شرکت‌های با کارآمدی بالا این کار را نمی‌کنند. آنها می‌گویند: همه نرم‌افزارهای ما در پردازش‌های حساس دخیل نیستند. فقط این سرویس خاص است که پردازش حساسی را انجام می‌دهد بنابراین کاری که می‌کنیم این است که حیطه مقررات را به کمترین سطح ممکن محدود می‌کنیم و طوری معماری می‌کنیم که نرم‌افزاری که آن کار را می‌کند تا حد ممکن کوچک باشد. بنابراین شما از رهیافتی با تفاوت ناچیز در مدیریت ریسک بهره می‌گیرید که در واقع در آن می‌گویید: مناطق ریسک کجاست؟ و چطور می‌توانیم مدیریت ریسک را طوری بکار بگیریم که بر کل سیستم اثر نگذارد؟ بنابراین برای برخی از سیستم‌ها، توسعه‌دهندگان می‌توانند تغییرات را به محیط عملیاتی بفرستند و برای برخی دیگر که داده‌های حساس دارد، از رهیافت متفاوت استفاده می‌کنیم.

شرکت Etsy هم PCI DSS دارد. PCI DSS بیان‌گر جداسازی وظایف است. به عبارت دیگر فردی که تغییرات را تأیید می‌کند به سراغ کسی که کد را می‌نویسد می‌رود اما هیچ‌گاه گفته نشده که این دو فرد نمی‌توانند کنار یکدیگر بنشینند. به عنوان مثال درEtsy افرادی که درمحیط PCI DSS کار می‌کنند شامل توسعه‌دهنده‌ها، تسترها، مسئولین عملیات، همگی در یک اتاق با هم هستند و کل وقت با هم صحبت می‌کنند. آن‌ها مقررات را به روشی پیاده‌سازی کرده‌اند که از روح و هم لفظ قوانین پیروی کنند اما خیلی مهم است که به روشی نباشد که خیلی سنگین و جداسازی شده باشد.

من نقلی از کتاب‌تان خواندم که: "هر کسی مسئول فرآیند تحویل است." آیا این جمع‌بندی DevOps است؟

بله، جمع‌بندی خیلی خوبی است. درست است، هر کسی مسئول فرآیند تحویل است. من فکر می‌کنم همه مسئول همه چیز هستند. اگر به سازمان‌های با کارآمدی بالا توجه کنید، توسعه‌دهندگان خود را مسئول نتایج کسب و کار می‌دانند. این‌طور نیست که بگویند شغل و مسئولیت من فلان چیز است و به‌غیر از آن، چیزهای دیگر، مشکل من نیست و مربوط به دیگران است. در سازمان‌های با کارآمدی بالا افراد این‌طور فکر نمی‌کنند. آن‌ها فکر می‌کنند همه چیز مشکل خودشان است.

سئوالی که در گزارش وضعیت DevOps پرسیدیم این بود که وقتی Dev و Ops با هم تعامل می‌کنند، آیا عموماً نتیجه برد-برد خواهد بود؟ و آیا این سئوال کلیدی بود که باعث توجه به DevOps شد؟ اگر به زمینه‌های فرهنگی که این خروجی‌های خوب را تولید کرده است نگاه کنید، به این صورت است که توسعه‌دهندگان، مسئولیت عملیات (operations) را می‌پذیرند و اگر مشکلی در عملیات رخ دهد، این‌طور برخورد نمی‌کنند که این اشتباه Ops است. به طریق مشابه، اگر فرآیند استقرار شکست بخورد، این‌طور برخورد نمی‌شود که از توسعه دهندگان نادان بوده است بلکه با هم کار می‌کنند و شرکت را طوری سازماندهی می‌کنیم تا همه افراد (توسعه‌دهندگان و بقیه) تا حد ممکن با مشتریان در تماس باشند. این هم ایده دیگری است که به روش تَرکه‌ای (lean) برمی‌گردد.

آیا مهم است که افرادی که بر روی توسعه تمرکز دارند و افرادی که بر عملیات تمرکز دارند کنار یکدیگر بنشینند؟

من فکر می‌کنم خیلی مهم است. یکی از کتاب‌های واقعاً خوبی که در ارتباط با روش تَرکه‌ای (lean) دوست دارم، کتاب تویوتا کاتا نوشته مایک رودر است. تویوتا کاتا، کتابی است که فلسفه مدیریتی بهبود مستمری که تویوتا از آن پیروی می‌کند را توضیح می‌دهد که واقعاً برای پیاده‌سازی این ایده‌ها کلیدی است. یکی از چیزهایی که او می‌گوید این است که شکل سازمان‌ها نیست که تعیین کننده است، بلکه رفتار افراد است. خیلی از شرکت‌ها برای رسیدن به برخی چیزهایی که در مورد آن صحبت کردیم، به نوعی تغییر ساختاری می‌پردازند اما لزوماً تغییر ساختار برای رسیدن به نتیجه کافی نیست، آن‌چه باید تغییر کند، رفتار افراد است.

و اگر کنار یکدیگر ننشینند، چطور می‌توان رفتار افراد را تغییر داد؟

این سئوال خیلی خوبی است و فکر می‌کنم کاملاً درست است یعنی کنار یکدیگر نشستن یکی از راه‌های این کار است. اگر به شرکت‌هایی مانند گوگل و فیسبوک نگاه کنید البته گوگل را که می‌دانم قطعاً این‌جور است، آن‌ها سرویس‌هایی دارند و این‌طور نیست که بر روی یک سرویس مثلاً دو تیم یا تنها ده نفر کار کند بلکه در مورد برخی سرویس‌ها، ده‌ها فرد با هم فعال هستند. آن‌ها اطمینان یافته‌اند که این افراد در یک طبقه باشند. ممکن است یک میز داشته باشید که تعدادی توسعه‌دهنده دور آن باشند و یک میز داشته باشید که تعدادی کارمند عملیات آنجا باشند، همگی دور یک میز نیستند اما همگی در یک طبقه هستند.

اما گوگل و آمازون توسعه‌دهنده‌های روشن فکر و با تفکرات رو به جلویی دارند و نه آدم‌های قدیمی که نمی‌خواهند تغییری بدهند.

درسته. این یکی از مؤلفه‌هایش است. داستان مورد علاقه من در ارتباط با تغییر فرهنگی، مجدداً یک مطالعه موردی از تویوتا است البته این فقط یکی از منابع است چون ما مدت طولانی است که داریم این کار را انجام می‌دهیم و داستان‌های خوب زیادی وجود دارد. این داستان، که در شبکه این زندگی آمریکایی، منتشر شده است در واقع یکی از پادکست‌های مورد علاقه من است. در آنجا در مورد NUMMI (مخفف New United Motor Manufacturing Inc)‌ صحبت می‌شود که یک طرح مشارکتی است که بین تویوتا و جنرال موتورز آمریکا، تنظیم شده است. من در کالیفرنیا زندگی می‌کنم، NUMMI در همان سایت قبلی جنرال موتورز بود که «فری‌مانت اسمبلی» خوانده می‌شد. فری‌مانت اسمبلی، بسته شد زیرا کیفیت خودروهای تولیدی واقعاً افتضاح بود. در آنجا، کارمندان خط تولید آدم‌های نگون‌بختی بودند که از شغل‌شان متنفر بودند و در کارشان خراب‌کاری می‌کردند. مثلاً قوطی‌های خالی نوشابه را درون در ماشین قرار می‌دادند تا موقع باز و بسته کردن سر و صدا کند یا این‌که هنگام کار الکل می‌نوشیدند بنابراین، کارخانه به علت به صرفه نبودن و کیفیت پایین بسته شد. وقتی تویوتا برای تولید خودرو به آمریکا آمد -چون کنگره، تعرفه‌ای برای ماشین‌های تولید خارج در نظر گرفته بود- جی‌.ام می‌خواست یاد بگیرد که چطور خودروهای کوچک بسازد زیرا جی‌.ام و دیگر تولیدکنندگان خودرو در آن زمان، خیلی سوخت مصرف می‌کردند و می‌خواستند بدانند چطور خودروهای کوچک اقتصادی بسازند. بنابراین آن طرح مشارکتی را در اوایل دهه ۸۰ بنا کردند. آن‌چه آن‌ها انجام دادند که خیلی غیرمعمول بود، این بود که از همان نیروی کار [قبلی] استفاده کردند. مدیر فری‌مانت اسمبلی، تویوتا را قانع کرد که همان نیروی کار قبلی را استخدام کند که [به نظر] کار احمقانه‌ای بود. اما آن‌ها، آن افراد را دوباره استخدام کردند و به شهر تویوتا در ژاپن فرستادند و آن‌ها را در سیستم تولید تویوتا، آموزش دادند و بعد همه آن‌ها برگشتند تا کار در NUMMI را آغاز کنند. بعد از چند هفته، آنها خودروهایی تولید می‌کردند که به همان کیفیت خودروهای تویوتا که در ژاپن تولید می‌شد، بود. آن‌ها تویوتای کَمِری می‌ساختند. آن‌ها خودروهایی می‌ساختند که از همه خودرو‌هایی که تا آن موقع جی‌.ام ساخته بود، با کیفیت‌تر بود. آن‌چه مشخص شد این بود که افراد مشکل نبودند، این سیستم بود که مشکل بود.

آن‌ها به غیر از این‌که یک سفر خوب به ژاپن داشتند، چه کردند؟

[سفر] یکی از مؤلفه‌های آن بود :-) مؤلفه‌ دیگر این بود که آن‌ها تازه اخراج شده بودند و آماده انجام هر کاری بودند. فکر می‌کنم هر دو مهم است اما نکته کلیدی که در پادکست در مورد تفاوت سیستم تولید در تویوتا به آن اشاره می‌شود، کار گروهی است. این‌که همه با هم کار می‌کنند تا به خروجی مطلوب مشتری برسند که در این مورد قبلاً هم صحبت کردیم.
یک رویه‌ای که همه در مورد آن صحبت می‌کنند این است که بتوان خط تولید را متوقف کرد. در کارخانه قبلی جی.ام چیزی که رخ می‌داد به این صورت بود که یک خودرو وارد خط تولید می‌شد و شما به‌عنوان یک کارگر، زمان مشخصی قبل از آنکه خودرو از محدوده شما خارج شود، برای انجام کارتان در کل آن فرآیند را داشتید و به‌عنوان مثال اگر نمی‌توانستید درِ خودرو را در زمانی که داشتید متصل کنید، خودرو راهش را به سمت فرد دیگر ادامه می‌داد و اتفاقی که می‌افتاد این بود که خودروهایی در خط جریان می‌یافتند که کارهایشان بد انجام شده بود یا درست کار نمی‌کرد. در انتها، انبوهی از آن‌ها در پارکینگ جمع می‌شد تا بعداً درست شود.

در تویوتا، کارها این‌طور انجام نمی‌شود. در تویوتا اگر نتوانید در مثلاً دو سوم زمان تعیین شده کار را انجام دهید، می‌توانید یک طناب که طناب اَندن (andon cord) نامیده می‌شود را بکشید تا یک علامت را روشن کند و مدیر برای کمک شما بیاید. در آن زمان این ایده که مدیر برای کمک شما بیاید برای جی‌.ام خیلی غیرمعمول بود :-) زیرا آنجا یک رابطه خیلی خصومت‌آمیزی بود اما در تویوتا، مدیر به کمک شما می‌آمد و اگر نمی‌توانستید کارتان را انجام دهید، دوباره طناب را می‌کشید و کل خط تولید را متوقف می‌کردید. این صحبت‌ها برای کارمندان جی‌.ام احمقانه به نظر می‌رسید و متوجه نشده بودند که هر چند یک‌بار طناب اندن، کشیده خواهد شد. ممکن است فکر کنید که طناب چند بار در روز کشیده می‌شود اما در تویوتا، طناب اندن، هزاران بار در روز کشیده می‌شود.

این‌ها باعث متوقف شدن خط می‌شود یا به معنای این است که من به کمک نیاز دارم؟

هر روزه چندین هزار بار به معنای من به کمک نیاز دارم کشیده می‌شود.

و برای متوقف کردن خط فقط چند بار در روز است؟

من دقیقاً نمی‌دانم هرچند یک‌بار خط متوقف می‌شود اما قطعاً این اتفاق می‌افتد. ایده این است که همه با هم کار می‌کنند و در این‌جا مهم‌ترین چیز، دوباره همان مفهوم جیدوکا است، این ایده که کیفیت را درون کار قرار دهید که یک روش کاملاً متفاوت است. جان شوک در مقاله‌ای که فکر می‌کنم در مجله مرور مدیریت سلحشوری (sloan management review) منتشر شد می‌گوید: «چیز بزرگی که تغییر کرد، دادن ابزار و مهارت‌ به کارگران برای انجام کارشان و قدرت بخشیدن به آن‌ها برای رسیدن به خروجی مطلوب مشتریان بود.» این تغییرات رفتاری است که خیلی اساسی است.

بنابراین در قیاس، [در مهندسی نرم‌افزار شامل] این‌ها است: پیاده‌سازی یکپارچه‌سازی مستمر، اجازه دادن به مهندسان که ابزار خودشان را انتخاب کنند، اجازه دادن به مهندسان که کدها را به محیط عملیاتی بفرستند، توانایی دادن به مهندسان برای تأثیرگذاری بر روی خروجی‌های قابل عرضه به مشتری، توانایی دادن به ایشان برای یادگیری خروجی‌های مطلوب مشتریان، در تماس قرار دادن آن‌ها با مشتری، دادن ابزارهایی که برای کار به آن نیاز دارند، همین‌طور آموختن به ایشان که ماحصل مطلوب ما به‌عنوان یک شرکت چیست، نگفتن اینکه چه ویژگی‌هایی می‌خواهیم بلکه گفتن خروجی‌های کسب و کار که می‌خواهیم به آن برسیم به ایشان و این‌که آن‌ها، مسئول آن ویژگی‌هایی هستند که می‌خواهیم بسازیم.

بیایید کمی از فرهنگ به سمت رویه‌ها جابجا شویم. از گفته‌های شما است که یکی از مهمترین رویه‌ها این است که همه چیز در مخزن کنترل نسخ (source control) قرار بگیرد. چرا این‌طور است؟

قرار دادن همه چیز در مخزن کنترل نسخ به چند دلیل اهمیت دارد: نخست آنکه می‌توانید تست‌های خودکار در سطح سیستم انجام دهید. دوست دارم بگویم که از کار انداختن یک سیستم وب با استفاده از تغییر در تنظیمات فایروال نسبت به از کار انداختن آن با تغییر در تنظیمات کد، بسیار ساده‌تر است. بنابراین می‌توانیم این تغییرات پرریسک را با همان نرخی تست کنیم که تغییرات کد را تست می‌کنیم. فکر می‌کنم مسائلی از قبیل شبکه‌های تعریف شده با نرم‌افزار (software defined networking) آن را در آینده حتی ساده‌تر هم خواهد کرد. ما باید تغییرات در شِمای پایگاه داده را تست کنیم. همه این جور تغییرات مختلف باید تست شود. بنابراین تا زمانی‌ که چیزها در مخزن کنترل نسخ قرار نگرفته باشد، نمی‌توانید تدارک چنین کارهایی را ببینید و تست‌های مربوط به تغییرات پایگاه داده را در فرآیند تست خودکار اجرا کنید.

دلیل دیگری که اهمیت دارد، به لحاظ معیارهای پایداری است. ما در این مورد صحبت کردیم که زمان بازراه‌اندازی یک سرویس، چه معیار مهمی است. در هنگام رخداد خرابی، مهم است که بتوانید سرویس را در یک مدت زمان قابل پیش‌بینی، بازراه‌اندازی کنید. تنها راهی که می‌توانید این‌کار را انجام دهید این است که پیکربندی سیستم عملیاتی خود را مجدداً از اطلاعات موجود در مخزن کنترل نسخ، بسازید. بنابراین تنها از لحاظ ترمیم خرابی هم که در نظر بگیریم، مسأله خیلی مهمی است که بتوانیم این کار را انجام دهیم. هر چیزی که بخشی از داده‌های شماست باید در مخزن کنترل نسخ قرار بگیرد.

اینجا هم تقریباً مانند همیشه همین‌طور است که چیزهایی که باعث افزایش توان عملیاتی (throughput) می‌شوند، باعث افزایش پایداری (stability) هم می‌شوند. بنابراین قرار دادن چیزها در مخزن کنترل نسخ، باعث افزایش هر دو این‌ها می‌شود، باعث افزایش توان عملیاتی می‌شود چراکه این امکان را می‌دهد که محیط تست خود را خیلی سریع‌تر تدارک ببینید و همین‌طور باعث افزایش پایداری می‌شود زیرا این امکان را می‌دهد که هنگام ترمیم خرابی سریع‌تر سیستم را مستقر کنید.

شما کمی قبل از این مصاحبه یک صحبت داشتید که در آن گفتید که اگر انشعاب (Branch) بگیرید، دیگر یکپارچه‌سازی مستمر ندارید. آیا ممکن است برای افرادی که آنجا نبوده‌اند، دراین‌باره توضیح دهید.

بله، فکر می‌کنم الان، این بحث‌برانگیزترین چیزی باشد که می‌گویم. این‌که انشعاب‌های مربوط به ویژگی‌های جدید (feature branch) اساساً ایده بدی است. من می‌توانم آن را به‌عنوان شعار بکار برم اما حقیقت ظریف‌تر از این است. مشکل، انشعاب‌‌های مربوط به ویژگی‌ها نیستند بلکه انشعاب‌های طولانی‌مدت ویژگی‌ها هستند و به طور خاص، انشعاب‌های ویژگی که تغییرات زیادی در آن‌ها قرار دارد.

در واقع مشکل از انشعاب گرفتن نیست، مشکل از ادغام کردن (merge) است. اگر تنها دو توسعه‌دهنده باشند، خوب است اما وقتی تعداد توسعه‌دهندگان افزایش می‌یابد، آنچه رخ می‌دهد این است که من بر روی کدهایم در انشعاب مربوط به یک ویژگی کار می‌کنم و ممکن است تولید آن ویژگی چند روز طول بکشد و بعد یک سری ریفاکتورهای خیلی خوب پیدا کنم که کد را خیلی بهتر کند. بنابراین در یک ارسال شبانه، آن ریفاکتورها را به شاخه اصلی (master) می‌فرستم. در همان زمان، شما دارید بر روی ویژگی دیگری کار می‌کنید و احتمالاً چند روزی است که دارید روی آن کار می‌کنید. شما تغییرات من که شامل ریفاکتورهای من است را می‌گیرید اما بالقوه ادغام کردن آن ریفاکتورها خصوصاً اگر یک معماری ایده‌آل نداشته باشید، ممکن است برای شما زجرآور باشد. این زجر با افزایش تعداد افراد تیم به‌صورت غیرخطی افزایش می‌یابد. هر چه تعداد افراد تیم بیشتر باشد، ادغام زجرآورتر می‌شود و هر چه که طول انشعاب‌ها بیشتر باشد، باز هم زجرآورتر می‌شود.

در واقع، وقتی عادات خوبی از قبیل ریفاکتور، دارید از آنجایی که همه افراد تیم که چند روزی است بر روی چیزهای دیگر کار می‌کنند، را مجبور می‌کنید که آن را گرفته و ادغام کنند و این می‌تواند بر روی کار همه آن‌ها تأثیر بگذارد. در این شرایط، ممکن است به ناگاه خیلی معروف ‌شوید :-)

فقط برای این که روشن‌تر شود، منظورتان از ادغام، بخش فنی آن نیست زیرا با ابزار git، ادغام در سطح کد خیلی راحت انجام می‌شود.

این هست اما ادغام معنایی را (semantic marge) هم داریم که متفاوت با ادغام متنی (text merge) است. من این را تجربه کرده‌ام و مطمئنم خیلی از مخاطبین شما هم این را تجربه کرده‌اند که کدی را داشته‌اند که خیلی خوب ادغام می‌شده اما همچنان باعث خرابی چیزی می‌شده است. زیرا ادغام ، شامل ناسازگاری (conflict) دو خط از کد نبوده، بلکه شامل ناسازگاری از این جهت بوده که یک جا یک تابع یا متدی فراخوانی می‌‌‌شده اما الان به‌جای آن، متد دیگری فراخوانی می‌شود اما فرد دیگری آن متد را عوض کرده است. در این شرایط ناسازگاری (متنی) وجود ندارد اما رفتار سیستم عوض شده است و ما متوجهش نشده‌ایم.

و اگر خوش‌شانس باشید کامپایلر یا تست‌های واحد (unit tests) متوجهش می‌شوند.

قطعاً، اگر کار نوشتن تست‌های واحد (unit test) را خوب انجام داده باشید، آن‌ها متوجهش می‌شوند. اما [این خطاها] تنها زمانی کشف می‌شوند که کدهایی که از لحاظ معنایی با یکدیگر در تعارض‌اند در یک مخزن کد (code base) قرار داشته باشند. وقتی ادغام بین انشعاب‌های مربوط به ویژگی‌ها فقط از طریق ادغام شاخه اصلی در یک انشعاب مربوط به ویژگی انجام می‌شود، این شرایط می‌تواند رخ دهد. تنها راهی که بتوانید سیستم را عملیاتی کنید این است که همه انشعاب‌های مربوط به ویژگی‌ها را با هم ادغام کنید و این یک مسأله ترکیبی (combinatorical) و نه خطی است.

بسیار خوب، روشن است که یک بخش از این گفته که همه چیز باید در مخزن کنترل نسخ قرار گیرد همان مبحث مدیریت پیکربندی (configuration management) است. مدیریت پیکربندی چیست؟

سئوال خوبی است زیرا افراد مختلف، آن را به روش‌‌های مختلفی بکار می‌برند. من فکر می‌کنم مدیریت پیکربندی، برنامه‌ریزی چگونگی تبدیل چیزهای موجود در مخزن کنترل نسخ به یک سیستم اجرایی است.

بنابراین ما داریم در مورد ابزارهایی از قبیل Puppet ، Chef و Ansible صحبت می‌کنیم.

بله، طیف کاملی از آنها وجود دارد. معلوم است که من در Chef هستم و نمی‌توانم بگویم که خیلی خوب کار می‌کند. اما طیف کاملی از ابزارها در بازار وجود دارند که تکه‌ها را از مخزن کنترل نسخ برمی‌دارند و آن‌ها را به یک سیستم اجرایی تبدیل می‌کنند. معمولاً فقط به ابزار مدیریت پیکربندی نیاز ندارید بلکه به دسته‌ای از ابزارهای دیگر هم نیاز دارید، هر کاری در این حیطه قرار می‌گیرد: ساختن بسته نرم‌افزار، امور شبکه (networking)، ذخیره‌سازی (storage)، ...

و پیکربندی فایروال‌ها یا سرورهای برنامه (application servers)، ...

قطعاً. هر چیزی، هر چیزی که برای بازسازی یک سیستم اجرایی نیاز داشته باشید، در این حیطه قرار می‌گیرد. این‌ها ساده‌تر شده است اما قطعاً یک مسأله حل شده به‌شمار نمی‌رود.

اخیراً جنبشی هست که از مدیریت پیکربندی، به سمت محفظه‌سازی (containerization) برویم مانند آنچه با Docker انجام می‌دهید. آیا این نیز در برنامه تحویل مستمر قرار دارد؟

بله، فکر می‌کنم Netflix از پیشگامان این قضیه بود. Netflix این ایده را داشت که واحدی که برای استقرار یا بسته‌بندی نرم‌افزار باید داشته باشیم، AMI است.

این AMI از چیزهای مربوط به مجازی‌سازی در آمازون است. درسته؟

بله، مخفف تصویر ماشین آمازون (Amazon Machine Image) است. در Netflix کاری که در خط لوله استقرار می‌کنند این است که یک AMI می‌سازند و این AMI در خط لوله تا محیط عملیاتی پیش می‌رود بنابراین واحد بسته‌بندی و استقرارشان است. آن‌ها یک ابزار دارند که آن‌طور که یک نفر می‌گفت، Bakery خوانده می‌شود که آن AMI را می‌سازد و به خط تولید منتقل می‌کند.

آنچه ما در ابزارهایی مانند Docker می‌بینیم همان‌طور که شما اشاره کردید، حرکت به سمت این نوع واحد استقرار است. این نه تنها بر روی چرخه کار سیستم عملیاتی بلکه بر روی چرخه کار توسعه‌دهند‌ه‌ها هم تأثیر شگرفی دارد. فکر می‌کنم Vagrant با فراهم کردن این قابلیت که در سیستم‌های توسعه‌دهندگان، محیط‌های مشابه سیستم عملیاتی داشته باشیم، در روش تست نرم‌افزار، انقلابی ایجاد کرد. با ابزارهایی مانند Docker، می‌توانید همان کار را کرده و از آنها در همه مسیر فرآیند از توسعه‌دهنده تا محیط عملیاتی استفاده نمایید. بنابراین، بله، فکر می‌کنم این‌ها تغییرات شگرفی هستند و باید معماری سیستم‌تان را با درنظر گرفتن آن‌ها تنظیم کنید. اما اگر روی یک سیستم بدون پیشینه (greenfield system) کار نمی‌کنید، خیلی دشوار است که این چیزها را به آن بخورانید. و البته همواره جایی برای Chef و ابزارهای مدیریت پیکربندی هست زیرا فقط در آن ارتباط نیست بلکه در مورد همه زیرساخت‌های پشتیبانی شده است و یک بخش سطح بالا از این هم‌نوایی ابزارها را تشکیل می‌دهد. و همین‌طور همه موارد، مربوط به محفظه‌ها (container) نیست بلکه بعد از آن، باید آن‌ها (محفظه‌ها و سرورها) را به خوبی به هم متصل کنید تا به درستی کار کنند.

ما اخیراً اپیزودی در مورد Vagrant داشته‌ایم. در آینده نیز اپیزودهایی در مورد وب‌سرویس‌های آمازون و Docker خواهیم داشت. مخاطبان می‌توانند برای یادگیری بیشتر در مورد این ابزارها به آنها مراجعه کنند. فکر می‌کنم که آن‌چه می‌‌خواستم گفته شود به خوبی پوشش داده شد. آیا چیزی هست که بخواهید بگویید و من در موردش نپرسیده باشم؟

مورد دیگری که به نظر من خیلی جذاب است، خصوصاً در گزارش وضعیت DevOps آن را انجام دادیم، این است که می‌توانیم فرهنگ را کمّی‌سازی کنیم. مدلی که برای کمّی‌سازی فرهنگ استفاده کردیم، توسط ران وستروم ابداع شده بود. او یک روانشناس است که در ارتباط با ایمنی در حوزه صنایع بهداشت و هوانوردی مطالعه می‌کند. او مدلی ساخته است که بوسیله آن می‌تواند خروجی این‌گونه صنایع را پیش‌بینی کند. نکته جالب این بود که ما از مدل او در گزارش وضعیت DevOps استفاده کردیم تا کارایی صنعت IT را پیش‌بینی کنیم، همان مدلی که فرهنگ را پیش‌بینی می‌کرد، می‌توانست خلاقیت، پایداری و بازدهی را نیز پیش‌بینی کند. این مسئله چشم من را باز کرد. شما می‌توانید به گزارش وضعیت DevOps مراجعه کرده و ببینید که مدل وستروم چیست. در واقع آن را جان آلسپو برایم فرستاد. جان آلسپاور هم‌اکنون رئیس DevOps در Etsy است. من به او ایمیل می‌زنم و او با pdf های مربوط به مقالاتی که اخیراً خوانده و واقعاً دوست داشته جواب می‌دهد. به این روش من چیزهای زیادی از او گرفته‌ام و این مقاله یکی از آن‌ها است. در حال حاضر او در مقطع کارشناسی ارشد رشته ایمنی در دانشگاه لاند در سوئد درس می‌خواند.

به نظر من با تعامل داشتن با افرادی که در حوزه‌ها و صنایع دیگری مشغول هستند، می‌توانیم چیزهای زیادی یاد بگیریم و این مدل‌هایی که سال‌هاست که در حوزه‌های دیگر استفاده شده‌اند، کاربردهای واقعاً مهمی در توسعه نرم‌افزار دارند.

شما اخیراً از ThoughtWorks به Chef رفته‌اید. افراد چطور می‌توانند با شما در تعامل باشند؟ نقش شما در کسب و کار آن‌جا چیست؟

در Chef من یک نقش متمرکز داخلی دارم که با بکارگیری همه چیزهایی که در موردش صحبت کردم، کمک ‌کنم که سازمانی بسازم که‌ در همه بخش‌ها، سریع‌تر حرکت کند. من کتابی دارم، که Lean Enterprise نام دارد. این کتاب، اساساً به این شکل طراحی شده است که درباره همه موارد سازمانی، فرهنگی و معماری که افراد را از تحویل مستمر باز می‌دارد (همه مباحثی که پیش از این در موردش صحبت کردیم)، صحبت کرده و افراد را در این زمینه‌ها کمک می‌کند. معمولاً می‌گویند که: این روش خوبی به نظر می‌رسد اما به فلان دلیل یا بهمان دلیل، اینجا کار نمی‌کند. ما به این فلان و بهمان‌ها در این کتاب اشاره کرده‌ایم: دلایل مالی، مالکیتی، مدیریت ریسک، مدیریت پروژه، امور اداری و ... . همه این موارد در کتاب پوشش داده شده است. من خیلی از این ایده‌ها را به کار گرفته‌ام تا کمک کنم که Chef در همه بخش‌ها، سریع‌تر حرکت کند.

بسیار خوب، جالبه. چگونه می‌توانیم اطلاعات بیشتری از شما بدست آوریم؟ شما در توییتر هستید؟

بله، به آدرس jezhumble@. من یک وب‌سایت به آدرس continuousdelivery.com دارم. آدرس ایمیل من jez@chef.com است. اما بله، توییتر بهترین روش در تماس بودن با من است.

بسیار خوب، این قسمت تمام می‌شود. از وقتی که گذاشتید خیلی ممنونم. فکر می‌کنم خیلی جذاب بود.

از اینکه دعوتم کردید خیلی متشکرم.