چه زمانی این همکاری مفید است
راهاندازی دستی، تغییرات بدون سند و محیطهای ناهمگون تحویل را غیرقابل تکرار میکند. اتوماسیون وقتی مفید است که راه شفاف و قابل آزمون برای تغییر زیرساخت بسازد، نه زنجیره ابزار مبهمی دیگر.
تصمیمها پیش از اجرا
مرز ماژول، مالکیت state، پیکربندی محیط و جریان تأیید را تعریف میکنیم. Terraform و Bicep و ابزار پیکربندی متناسب با پلتفرم و تیم انتخاب میشوند. رمزها، drift، بازبینی و بازیابی باید در کنار استقرار عادی کار کنند.
معماری در بستر تصمیم
معماری مفهومی برای مرزهای تصمیم؛ محیط مشتری را نشان نمیدهد.
آنچه دریافت میکنید
- فهرست زیرساخت و پیکربندی
- رابط ماژولهای قابلاستفاده مجدد و ساختار محیط
- خط لوله اعتبارسنجی، برنامهریزی، بازبینی و استقرار
- رویههای state، رمز و مدیریت drift
- مستندات مخزن و تحویل عملیاتی
نحوه کنترل تحویل
- 01یک بنیاد یا بارکاری محدود را بهعنوان اولین برش اتوماسیون انتخاب کنید.
- 02پیکربندی را با مالکیت کنترلشده state وارد یا کدنویسی کنید.
- 03قبل از رسیدن تغییر به تولید اعتبارسنجی و بازبینی اضافه کنید.
- 04سناریوهای تغییر، شکست و بازیابی را اجرا کنید.
- 05دسترسی مخزن، مستندات و مسئولیت نگهداری را منتقل کنید.
مرزها و مقایسه گزینهها
اتوماسیون انتخابهای معماری یا تأیید تغییر را حذف نمیکند. state بدون مدیریت و انتزاع بیش از حد میتواند ریسک را بالا ببرد. ماژولهایی را ترجیح میدهیم که مردم بتوانند بفهمند، بازبینی و نگهداری کنند.
پرسشها و پاسخها
چه زیرساختی را باید اتوماسیون و تحویل دهیم؟
بنیان و تحویل ابری را با Infrastructure as Code قابلاستفاده مجدد، تغییرات کنترلشده و تحویل عملیاتی عملی کدنویسی کنید.
#تیم ما در زمان تحویل چه انتظاری داشته باشد؟
تحویل شامل فهرست زیرساخت، رابط ماژول و ساختار محیط و خط لوله اعتبارسنجی و استقرار است. شواهد پذیرش و مالک مستمر را پیش از اجرا توافق میکنیم.
#برای گفتگوی اول چه چیزی بیاوریم؟
هدف کسبوکار، معماری فعلی، مالکان بارکاری، محدودیتهای عملیاتی و مهلتهای ثابت را بیاورید تا تصمیمها و دسترسیهای لازم این همکاری مشخص شود.
#حوزه، هزینه و زمان تحویل چگونه تعیین میشود؟
ابتدا بارکاری و وابستگیها را محدود میکنیم. خروجیهای موردنیاز، آمادگی دسترسی، پوشش آزمون و پنجرههای تأیید برنامه تحویل را مشخص میکند؛ پیش از کشف، قیمت یا زمانبندی ثابت فرض نمیکنیم.
#