چرا Devcontainerها به روش پیشفرض شروع کدنویسی تبدیل میشوند
برای مدت طولانی، شروع یک پروژه نرمافزاری جدید به معنای باز کردن راهنمای راهاندازی، نصب لیستی از زماناجراهای زبان، رفع ناسازگاریهای نسخه، دنبال کردن پکیجهای سیستمی گمشده و امیدوار بودن به اینکه لپتاپ شما در نهایت شبیه لپتاپ بقیه شود، بود. تیمها این دردسر را عادی میدانستند. این بخشی از توسعهدهنده بودن بود. اما با توزیعپذیرتر شدن سازمانهای نرمافزاری، افزایش آگاهی امنیتی و وابستگی بیشتر به تحویل تکرارپذیر، مدل قدیمی به جای اجتنابناپذیر بودن، گران به نظر میرسد. این پیشزمینهای است برای اینکه چرا devcontainerها از یک راحتی خاص به نقطه شروع پیشفرض تبدیل میشوند.
مشخصات Development Containers، یک dev container را به عنوان یک محیط توسعه کامل توصیف میکند که میتواند به صورت محلی یا از راه دور اجرا شود. این تعریف فنی به نظر میرسد، اما دلیل اهمیت آن برای تیمها ساده است. یک devcontainer به پروژه اجازه میدهد تا محیط توسعه خود را با خود حمل کند: زماناجراها، ابزارها، افزونهها، تنظیمات شل، سرویسها و پیکربندی. به جای اینکه هر توسعهدهنده محیط را از ابتدا بسازد، مخزن آن را یک بار تعریف میکند و تیم آن را در همه جا استفاده مجدد میکند.
پذیرش (Onboarding) اکنون یک مسئله محصولی است
یکی از واضحترین دلایلی که devcontainerها در حال پیشرفت هستند، پذیرش (onboarding) است. در بسیاری از تیمها، سختترین بخش هفته اول یک مهندس جدید، درک کدبیس نیست. بلکه راهاندازی کد است. این اصطکاک پرهزینه است. بهرهوری را به تأخیر میاندازد، کار پشتیبانی قابل اجتناب برای مهندسان ارشد ایجاد میکند و سیگنال ظریفی میفرستد که کیفیت ابزارهای داخلی اهمیتی ندارد. Devcontainerها با تبدیل راهاندازی به یک مصنوع که میتواند مانند کد برنامه نسخهبندی و بهبود یابد، مستقیماً به این مشکل حمله میکنند.
این تغییر اهمیت دارد زیرا پذیرش دیگر فقط یک نقطه عطف منابع انسانی نیست. این یک مسئله سیستمهای مهندسی است. اگر یک تیم بتواند از "این صفحه ویکی را دنبال کنید و وقتی خراب شد در Slack بپرسید" به "مخزن را باز کنید و در یک محیط شناختهشده و خوب شروع کنید" حرکت کند، قابلیت اطمینان، اعتماد به نفس و سرعت را بهبود میبخشد. این مزیت با رشد تیمها، به ویژه در سیستمعاملها و مناطق زمانی مختلف، چند برابر میشود.
انحراف محیطی اکنون بیش از حد گران است
انحراف توسعه محلی قبلاً تحمل میشد زیرا تیمها کوچکتر و پشتههای نرمافزاری سادهتر بودند. امروزه، یک برنامه مدرن ممکن است به چندین سرویس، نسخههای دقیق کامپایلر، الگوهای تزریق راز، CLIهای پلتفرم، ابزارهای اتوماسیون مرورگر و شبیهسازهای زیرساخت وابسته باشد. هرچه قطعات متحرک بیشتری وجود داشته باشد، احتمال اینکه "روی دستگاه من کار میکند" یک شوخی نباشد بلکه یک هزینه عملیاتی تکراری باشد، بیشتر میشود.
Devcontainerها با تعریف اعلانی محیط، این انحراف را کاهش میدهند. اگر مخزن میگوید یک پروژه به یک نسخه خاص Node، یک سرویس پایگاه داده، یک مدیر بسته و یک زنجیره ابزار linting نیاز دارد، این تعریف میتواند در ویرایشگرها و ماشینها منتقل شود. ویژگیها و الگوها (Templates) با اجازه دادن به تیمها برای ترکیب بلوکهای ساختمانی مشترک به جای بازنویسی همه چیز برای هر پروژه، مدل را قابل استفاده مجددتر میکنند. این دلیل بزرگی است که تیمهای پلتفرم و تجربه توسعهدهنده آنها را دوست دارند. استانداردسازی بدون مجبور کردن هر تیم به استفاده از یک پشته دقیقاً یکسان، عملی میشود.
برابری CI مکالمه را تغییر میدهد
دلیل دیگری که devcontainerها به طور فزایندهای پیشفرض به نظر میرسند، رابطه آنها با CI و تست است. تیمهای مهندسی تحت فشار دائمی هستند تا توسعه محلی، تست خودکار و محیطهای نزدیک به تولید را بیشتر با هم هماهنگ کنند. هر عدم تطابق بین فرضیات محلی و واقعیت CI، حلقههای بازخورد کندی ایجاد میکند. یک توسعهدهنده به صورت محلی یک بیلد سبز دریافت میکند، سپس منتظر میماند تا CI وابستگیهای از دست رفته، تفاوتهای شل یا فرضیات پنهان محیطی را آشکار کند.
هنگامی که تیمها از کانتینرها برای تعریف محیطهای توسعه استفاده میکنند، به دنیایی نزدیکتر میشوند که در آن اجرای محلی، از راه دور و خودکار، پایه مشترک بیشتری دارند. این به معنای آن نیست که devcontainerها با تصاویر تولیدی یکسان هستند، و همیشه هم نباید باشند. اما به این معنی است که محیط به یک سطح طراحی صریح تبدیل میشود. همین به تنهایی یک پیشرفت عمده نسبت به دانش قبیلهای مستند نشده لپتاپ است.
کار از راه دور و فضاهای کاری ابری به عادیسازی مدل کمک کردند
Devcontainerها همچنین از یک تغییر زیرساختی گستردهتر بهرهمند شدند. هنگامی که توسعهدهندگان با نوشتن کد در محیطهای از راه دور، فضاهای کاری موقت و IDEهای مبتنی بر مرورگر راحت شدند، ایده جداسازی ویرایشگر از ماشین دیگر عجیب به نظر نمیرسید. ابزارهایی مانند GitHub Codespaces این را آشکار کردند که همان محیط تعریف شده در مخزن میتواند روی یک لپتاپ، یک VM ابری یا یک پلتفرم تیمی مشترک اجرا شود. این قابلیت حمل، devcontainerها را از یک ترفند محلی Docker به یک استاندارد گردش کار تبدیل کرد.
این موضوع فراتر از راحتی اهمیت دارد. تیمهای امنیتی اغلب محیطهایی را ترجیح میدهند که وصله کردن، بازسازی و محدود کردن آنها آسانتر است. تیمهای پلتفرم دوست دارند بتوانند تصاویر پایه تأیید شده و الگوهای راهاندازی قابل استفاده مجدد را ارائه دهند. مدیران مهندسی دوست دارند زمان از دست رفته به دلیل مسائل راهاندازی سفارشی را کاهش دهند. Devcontainerها در تقاطع هر سه نگرانی قرار دارند، که یکی از دلایلی است که اکنون در بحثهای استراتژی ظاهر میشوند و نه فقط در بحثهای ترجیح توسعهدهنده.
جایی که devcontainerها میدرخشند
آنها زمانی میدرخشند که یک پروژه پیچیدگی راهاندازی قابل توجهی، مشارکتکنندگان متعدد یا نیاز به قابلیت بازتولید قابل اعتماد داشته باشد. آنها به ویژه برای مخازن چندزبانه (polyglot repos)، برنامههای سنگین زیرساختی، محیطهای آموزشی، پروژههای متنباز با مشارکتکنندگان جدید زیاد، و تیمهایی که خواهان انتقالهای تمیزتر بین توسعه محلی و از راه دور هستند، ارزشمندند. آنها همچنین زمانی کمک میکنند که سازمانها بخواهند تجربه توسعهدهنده را به عنوان یک قابلیت پلتفرم داخلی به جای یک بار پشتیبانی غیررسمی در نظر بگیرند.
در عمل، devcontainerهای خوب اسناد راهاندازی را کاهش میدهند، زمان پذیرش (onboarding) را کوتاه میکنند، انتخابهای محیطی را در بازبینی کد آشکار میسازند و آزمایش گردش کارهای امن یا ایزوله را آسانتر میکنند. آنها همچنین یک پیشفرض بهتر برای توسعه موقت ایجاد میکنند. یک وضعیت محلی خراب کمتر ترسناک میشود وقتی محیط را بتوان از پیکربندی بازسازی کرد به جای اینکه به صورت دستی به حالت اولیه بازگردانده شود.
جایی که هنوز مشکلساز هستند
هیچ یک از اینها devcontainerها را بدون اصطکاک نمیکند. توسعه کانتینری هنوز میتواند در برخی ماشینها کندتر باشد، با I/O فایل سنگین ناخوشایند باشد، و زمانی که پروژهها به یکپارچگی عمیق با میزبان، دسترسی به سختافزار سفارشی یا ابزارهای خاص پلتفرم نیاز دارند، ناامیدکننده باشد. تیمها همچنین میتوانند راهاندازی خود را بیش از حد مهندسی کنند و تصاویر عظیمی ایجاد کنند که ساخت و بهروزرسانی آنها دردناک است. یک devcontainer بد میتواند به سادگی یک نوع دردسر محیطی را با نوع دیگری جایگزین کند.
یک تله فرهنگی نیز وجود دارد. تیمها گاهی اوقات فرض میکنند که انتقال راهاندازی به یک کانتینر به طور خودکار تجربه توسعهدهنده را بهبود میبخشد. اینطور نیست. اگر محیط به خوبی نگهداری نشود، مبهم باشد یا با ابزارهای اختیاری بیش از حد بارگذاری شود، همان سردرگمی فقط به سردرگمی قابل بازتولید تبدیل میشود. Devcontainerها زمانی بهترین عملکرد را دارند که تیمها آنها را به عنوان یک سطح محصولی در نظر بگیرند که شایسته مالکیت، تکرار و توجه به عملکرد است.
چرا پیشفرض به معنای جهانی نیست
Devcontainerها در حال تبدیل شدن به روش پیشفرض برای شروع کدنویسی هستند زیرا چندین مشکل مهندسی مدرن را به طور همزمان حل میکنند: پذیرش (onboarding)، انحراف، برابری و قابلیت حمل. این به معنای آن نیست که هر پروژه باید به یک روش از آنها استفاده کند. اسکریپتهای ساده ممکن است به سربار اضافی نیاز نداشته باشند. گردش کارهای بومی موبایل یا سنگین سختافزاری ممکن است هنوز به ابزارهای میزبان متکی باشند. برخی تیمها به دلایل عملکردی، راهاندازیهای محلی سبکتر را ترجیح میدهند.
اما روند گستردهتر هنوز واضح است. محیطهای توسعه دیگر فقط ترجیحات شخصی ایستگاه کاری نیستند. آنها بخشی از زنجیره تأمین نرمافزار هستند. هنگامی که تیمها این را میپذیرند، محیطهای نسخهبندی شده و قابل حمل به یک خط پایه آشکار تبدیل میشوند. Devcontainerها به خوبی با این لحظه مطابقت دارند، به همین دلیل است که به طور فزایندهای کمتر شبیه یک ویژگی اختیاری برای کاربران حرفهای و بیشتر شبیه خط شروع مدرن به نظر میرسند.