🔀 گردش کار Git کارآمد برای برنامه های وب: پیشرفت تدریجی از ابتدا تا پیشرفت

Summarize this content to 400 words in Persian Lang

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

توسعه دهندگان، حتی افراد با تجربه، اغلب با Gitflow معروف مبارزه کرده اند:

با این حال، حقیقت این است که ما از روز اول به این پیچیدگی نیاز نداریم. بسیاری از توسعه دهندگان حتی استدلال می کنند که این سطح از پیچیدگی هرگز در هیچ موردی ضروری نیست، بلکه نشانه ای از یک مشکل سازمانی است.

بیایید متفاوت با آن برخورد کنیم: از نیازهای تیمی تا گردش کار.

همانطور که تیم را جمع آوری می کنیم و برای نوشتن اولین خطوط کد آماده می شویم، اعضای تیم توسعه چند الزام دارند:

یک پایه کد مشترک را به اشتراک بگذارید
در کار در حال پیشرفت همکاری کنید
انجام تست

اکثر برنامه های کاربردی وب از یک ماژول frontend و یک ماژول باطن تشکیل شده اند. سوال استفاده از مولتی ریپو یا مونو ریپو مطرح می شود.

این مقاله درباره موضوع بحث‌برانگیز توضیح نمی‌دهد، اما برای شروع یک پروژه برنامه کاربردی وب، ما یک مخزن مونو به دلایل زیر انتخاب می‌کنیم:

بدون نیاز به نسخه داخلی
وابستگی های ماژول مشترک محلی
یک ویژگی، یک شاخه ویژگی
ادغام مداوم آسان

در این مرحله از پروژه، به شعبه های زیر بیشتر نیاز نداریم:

شاخه های ویژگی کوتاه مدت که در آنها ادغام می شوند main در صورت آماده شدن، هر چند وقت یکبار
الف main شعبه برای کد ادغام شده

در هفته های اولیه آزمایش و نمایش، رایانه های محلی کافی است. این به مهندس پلتفرم زمان می دهد تا محیط های واقعی را آماده کند.

برای بررسی کد، هر پلتفرم Git، مانند GitLab یا GitHub، کافی است.

گردش کار

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

برای دستیابی به این هدف، ما یک محیط یکپارچه ایجاد می کنیم که منعکس کننده آن است main شاخه

اگر فناوری‌های مناسب CI/CD را داشته باشیم، می‌توانیم محیطی را برای هر شاخه ایجاد کنیم که کارایی تیم را بسیار افزایش می‌دهد. Kubernetes و GitLab می توانند به ما در رسیدن به این هدف با حداقل تلاش کمک کنند.

گردش کار Git ما در این مرحله به شکل زیر است:

شاخه های ویژگی کوتاه مدت و محیط های مربوط به آنها در ادغام می شوند main

main شعبه و محیط برای همکاری تیم توسعه و نمایش مشتری استفاده می شود

مخزن زیرساخت جداگانه؟

این موضوع بحث برانگیز و کمی خارج از موضوع است، اما این هنوز یک موضوع مرتبط با انتخاب کارایی در خطر است.

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

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

اما آیا واقعاً برای زیرساخت به اتوماسیون کامل نیاز داریم؟ در حالی که زیرساخت به عنوان کد مطلوب است، اتوماسیون استقرار ممکن است ضروری نباشد. ما دوست داریم از این قانون پیروی کنیم: “قبل از اینکه خسته کننده باشد، خودکار نکنید.” از آنجایی که محصول ما تازه شروع شده است، هیچ چیز در مورد زیرساخت خسته کننده نیست. لازم نیست هر هفته خوشه Kubernetes خود را مجدداً معرفی کنیم.

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

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

زمان معرفی است demo محیط زیست این محیط منعکس کننده محتوای main محیط و قبل از هر نمایش برنامه ریزی شده به روز می شود. در این میان ثابت می ماند.

برای تطبیق جریان، به روز رسانی می تواند توسط یک تگ Git یا یک شاخه Git راه اندازی شود. در اینجا، ما انتخاب می کنیم که یک جدید ایجاد کنیم demo شاخه گیت.

گردش کار Git ما اکنون به شکل زیر است:

شاخه های ویژگی کوتاه مدت و محیط های مربوط به آنها در ادغام می شوند main و سپس حذف شد

main شاخه و محیط در ادغام می شوند demo قبل از تظاهرات

demo شاخه و محیط برای نمایش استفاده می شود

با نزدیک شدن به MVP (حداقل محصول قابل دوام)، یک محیط تولید از ابتدا ساخته شده است و به زودی عمومی خواهد شد. زمان آن رسیده است که برنامه خود را در زیرساخت تولید هدف مستقر کنیم.

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

ما آبشاری ادغام از main به demo به production. را demo و production محیط ها چرخه های زندگی را از هم جدا کرده اند.

گردش کار Git ما اکنون به شکل زیر است:

شاخه های ویژگی کوتاه مدت و محیط های مربوط به آنها در ادغام می شوند main و سپس حذف شد

main شاخه و محیط در ادغام می شوند demo قبل از تظاهرات

demo شاخه و محیط برای نمایش استفاده می شود
کارهای استقرار تولید دستی روی برچسب ها (ایجاد شده در main یا demoبسته به ترجیح تیم)

همانطور که از ابتدا امیدوار بودیم، اکنون مشتریان خوشحالی داریم.

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

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

گردش کار Git ما اکنون به شکل زیر است:

شاخه های ویژگی کوتاه مدت و محیط های مربوط به آنها در ادغام می شوند main و سپس حذف شد

main شاخه و محیط در ادغام می شوند demo قبل از تظاهرات

demo شاخه و محیط برای نمایش استفاده می شود
خودکار staging استقرار و دستی production استقرار توسط برچسب ها آغاز می شود

ما هنوز به تعمیرات داغ تولید به طور جداگانه رسیدگی نمی کنیم. کل محتوای main برای تولید روی برچسب ها مستقر شده است. محتوای ناتمام در ادغام نمی شود main یا توسط یک commit غیرفعال می شود.

اکنون برنامه ما تا حدودی موفق است و مشتریان زیادی روزانه از آن استفاده می کنند.

پول نقد جریان دارد و تیم توسعه در حال رشد است. پیدا کردن یک رضایت بخش به طور فزاینده ای دشوار می شود main یا demo ایالتی که برای تولید مستقر شود.

اکنون زمان اضافه کردن کلیدهای ویژگی (همچنین به عنوان پرچم های ویژگی یا چرخاندن ویژگی شناخته می شود) است. هر چیزی را می توان در تولید مستقر کرد تا زمانی که توسط یک سوئیچ محافظت شود تا آن را فعال کند یا نه.

گردش کار Git ما اکنون به شکل زیر است:

شاخه های ویژگی کوتاه مدت و محیط های مربوط به آنها در ادغام می شوند main و سپس حذف شد

main شاخه و محیط در ادغام می شوند demo قبل از تظاهرات

demo شاخه و محیط برای نمایش استفاده می شود
خودکار staging و production استقرار توسط برچسب های ایجاد شده در راه اندازی می شود mainو کلیدهای ویژگی بر اساس اطمینان فعال می شوند

ما سفر یک پروژه شروع را دنبال کردیم که به تدریج فقط پیچیدگی لازم را به جریان git اضافه کرد.

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

بهترین تجربه شما از گردش کار Git چیست؟ لطفا در نظرات زیر به اشتراک بگذارید 🤓

تصاویر به صورت محلی توسط Pinokio با استفاده از پلاگین Stable Cascade ایجاد شده است

این مقاله با کمک یک مدل زبان هوش مصنوعی برای اطمینان از وضوح و دقت در محتوا بهبود یافته است، زیرا انگلیسی زبان مادری من نیست.