یک سیستم ساخت یکی از مهم ترین بخش های یک سازمان مهندسی است زیرا هر توسعه دهنده به طور بالقوه ده ها یا صدها بار در روز با آن تعامل دارد. یک سیستم ساخت کامل برای فعال کردن بهره وری توسعه دهندگان به عنوان مقیاس سازمان ضروری است. برای توسعه دهندگان منفرد، کامپایل کردن کدتان ساده است و بنابراین یک سیستم ساخت ممکن است بیش از حد به نظر برسد. اما در مقیاس بزرگ‌تر، داشتن یک سیستم ساخت به مدیریت وابستگی‌های مشترک کمک می‌کند، مانند تکیه بر قسمت دیگری از پایه کد، یا یک منبع خارجی، مانند کتابخانه. سیستم های ساخت کمک می کند تا مطمئن شوید که همه چیزهایی را که برای ساخت کد خود نیاز دارید، قبل از شروع ساخت، دارید. ساختن سیستم‌ها همچنین هنگام راه‌اندازی برای کمک به مهندسان در به اشتراک گذاشتن منابع و نتایج، سرعت را افزایش می‌دهند.
این بخش برخی از تاریخچه و اصول اولیه ساخت و ساز سیستم ها، از جمله تصمیمات طراحی که در ساخت Bazel انجام شد را پوشش می دهد. اگر با سیستم‌های ساخت مبتنی بر مصنوع مانند Bazel، Buck و Pants آشنا هستید، می‌توانید از این بخش صرفنظر کنید، اما این یک مرور کلی مفید است برای درک اینکه چرا سیستم‌های ساخت مبتنی بر مصنوعات در مقیاس‌بندی عالی هستند.
اگر قبلاً از یک سیستم ساخت استفاده نکرده اید، از اینجا شروع کنید. این صفحه به این موضوع اشاره می‌کند که چرا باید از یک سیستم ساخت استفاده کنید، و اینکه چرا کامپایلرها و اسکریپت‌های ساخت بهترین انتخاب نیستند، زمانی که سازمان شما شروع به گسترش بیشتر از چند توسعه‌دهنده کند.
این صفحه درباره سیستم‌های ساخت مبتنی بر وظیفه (مانند Make، Maven و Gradle) و برخی از چالش‌های آنها بحث می‌کند.
سیستم های ساخت مبتنی بر مصنوعات
این صفحه سیستم های ساخت مبتنی بر مصنوع را در پاسخ به نقاط دردسر سیستم های ساخت مبتنی بر وظیفه مورد بحث قرار می دهد.
این صفحه بیلدهای توزیع شده یا بیلدهایی که خارج از ماشین محلی شما اجرا می شوند را پوشش می دهد. این نیاز به زیرساخت قوی تری برای به اشتراک گذاشتن منابع و ایجاد نتایج دارد (و جایی است که جادوگری واقعی اتفاق می افتد!)
این صفحه برخی از عوارض وابستگی ها را در مقیاس بزرگ و استراتژی هایی برای مقابله با این عوارض پوشش می دهد.