این صفحه درباره اینکه سیستم‌های ساخت چیست، چه کار می‌کنند، چرا باید از یک سیستم ساخت استفاده کنید، و چرا کامپایلرها و اسکریپت‌های ساخت بهترین انتخاب نیستند، توضیح می‌دهد. این برای توسعه دهندگانی است که تجربه زیادی با یک سیستم ساخت ندارند.
سیستم ساخت چیست؟
اساساً، تمام سیستم های ساخت یک هدف مستقیم دارند: آنها کد منبع نوشته شده توسط مهندسان را به باینری های اجرایی تبدیل می کنند که می توانند توسط ماشین ها خوانده شوند. سیستم‌های ساخت فقط برای کدهای انسانی نیستند. آنها همچنین به ماشین‌ها اجازه می‌دهند تا به طور خودکار ساخت‌ها را ایجاد کنند، چه برای آزمایش و چه برای عرضه به تولید. در سازمانی با هزاران مهندس، معمول است که بیشتر ساخت‌ها به‌جای مستقیماً توسط مهندسان، به‌طور خودکار راه‌اندازی می‌شوند.
آیا نمی توانم فقط از یک کامپایلر استفاده کنم؟
نیاز به یک سیستم ساخت ممکن است بلافاصله آشکار نباشد. اکثر مهندسان هنگام یادگیری کدنویسی از یک سیستم ساخت استفاده نمی کنند: بیشتر آنها با فراخوانی ابزارهایی مانند gcc یا javac مستقیماً از خط فرمان یا معادل آن در یک محیط توسعه یکپارچه (IDE) شروع می کنند. تا زمانی که تمام کد منبع در یک دایرکتوری باشد، دستوری مانند این به خوبی کار می کند:
javac *.java
این به کامپایلر جاوا دستور می دهد تا هر فایل منبع جاوا را در دایرکتوری فعلی بگیرد و آن را به یک فایل کلاس باینری تبدیل کند. در ساده ترین حالت، این تنها چیزی است که شما نیاز دارید.
با این حال، به محض گسترش کد، عوارض شروع می شود. javac به اندازه کافی هوشمند است که در زیر شاخه های دایرکتوری فعلی جستجو کند تا کدی را برای وارد کردن پیدا کند. اما هیچ راهی برای یافتن کدهای ذخیره شده در سایر بخش‌های سیستم فایل (شاید کتابخانه‌ای که توسط چندین پروژه مشترک است) وجود ندارد. همچنین فقط می داند که چگونه کد جاوا بسازد. سیستم‌های بزرگ اغلب شامل قطعات مختلفی هستند که به زبان‌های برنامه‌نویسی مختلف نوشته شده‌اند و شبکه‌هایی از وابستگی‌ها در میان آن قطعات نوشته شده‌اند، به این معنی که هیچ کامپایلری برای یک زبان واحد نمی‌تواند کل سیستم را بسازد.
هنگامی که با کد از چندین زبان یا چندین واحد کامپایل سر و کار دارید، ساخت کد دیگر یک فرآیند یک مرحله‌ای نیست. اکنون باید ارزیابی کنید که کد شما به چه چیزی بستگی دارد و آن قطعات را به ترتیب مناسب بسازید، احتمالاً با استفاده از مجموعه‌ای از ابزارهای مختلف برای هر قطعه. اگر هر گونه وابستگی تغییر کرد، باید این فرآیند را تکرار کنید تا از وابستگی به باینری های قدیمی خودداری کنید. برای یک پایگاه کد حتی با اندازه متوسط، این فرآیند به سرعت خسته کننده و مستعد خطا می شود.
کامپایلر همچنین درباره نحوه مدیریت وابستگی های خارجی، مانند فایل های JAR شخص ثالث در جاوا، چیزی نمی داند. بدون سیستم ساخت، می توانید با دانلود وابستگی از اینترنت، چسباندن آن در پوشه lib روی هارد دیسک، و پیکربندی کامپایلر برای خواندن کتابخانه ها از آن دایرکتوری، این کار را مدیریت کنید. با گذشت زمان، حفظ به‌روزرسانی‌ها، نسخه‌ها و منبع این وابستگی‌های خارجی دشوار است.
در مورد اسکریپت های پوسته چطور؟
فرض کنید که پروژه سرگرمی شما به اندازه کافی ساده شروع می شود که می توانید آن را فقط با استفاده از یک کامپایلر بسازید، اما شروع به مواجهه با برخی از مشکلاتی که قبلا توضیح داده شد، می کنید. شاید هنوز فکر نمی‌کنید که به یک سیستم ساختنی نیاز دارید و می‌توانید با استفاده از چند اسکریپت ساده پوسته که از ساختن چیزها به ترتیب درست مراقبت می‌کنند، قطعات خسته‌کننده را به‌طور خودکار حذف کنید. این برای مدتی کمک می کند، اما خیلی زود با مشکلات بیشتری مواجه می شوید:
خسته کننده می شود. همانطور که سیستم شما پیچیده تر می شود، تقریباً به همان اندازه که روی کد واقعی کار می کنید، روی اسکریپت های ساخت خود وقت صرف می کنید. اشکال زدایی اسکریپت های پوسته دردناک است و هک های بیشتری روی هم قرار می گیرند.
خیلی آرومه. برای اطمینان از اینکه تصادفاً به کتابخانه‌های قدیمی اعتماد نکرده‌اید، باید اسکریپت بیلد خود را هر بار که آن را اجرا می‌کنید به ترتیب وابستگی ایجاد کند. شما در مورد اضافه کردن مقداری منطق فکر می کنید تا تشخیص دهید کدام قسمت ها نیاز به بازسازی دارند، اما این به نظر بسیار پیچیده و مستعد خطا برای یک اسکریپت است. یا به این فکر می کنید که هر بار مشخص کنید کدام قسمت ها نیاز به بازسازی دارند، اما پس از آن به نقطه اول باز می گردید.
خبر خوب: زمان انتشار فرا رسیده است! بهتر است تمام آرگومان هایی را که باید به دستور jar منتقل کنید تا ساخت نهایی خود را بسازید، بیابید. و به یاد داشته باشید که چگونه آن را آپلود کنید و آن را به مخزن مرکزی فشار دهید. و به‌روزرسانی‌های اسناد را بسازید و فشار دهید، و یک اعلان برای کاربران ارسال کنید. هوم، شاید این به اسکریپت دیگری نیاز دارد...
فاجعه! هارد دیسک شما خراب می شود و اکنون باید کل سیستم خود را دوباره بسازید. شما به اندازه کافی باهوش بودید که می‌توانید همه فایل‌های منبع خود را تحت کنترل نسخه نگه دارید، اما در مورد آن کتابخانه‌هایی که دانلود کرده‌اید چطور؟ آیا می توانید دوباره همه آنها را پیدا کنید و مطمئن شوید که همان نسخه ای هستند که برای اولین بار آنها را دانلود کردید؟ احتمالاً اسکریپت‌های شما به ابزارهای خاصی بستگی دارد که در مکان‌های خاصی نصب می‌شوند - آیا می‌توانید همان محیط را بازیابی کنید تا اسکریپت‌ها دوباره کار کنند؟ در مورد همه متغیرهای محیطی که مدتها پیش تنظیم کردید تا کامپایلر درست کار کند و سپس فراموش کرده اید چطور؟
با وجود مشکلات، پروژه شما به اندازه کافی موفق است که بتوانید مهندسان بیشتری را استخدام کنید. اکنون متوجه شدید که برای بروز مشکلات قبلی فاجعه ای لازم نیست - باید هر بار که یک توسعه دهنده جدید به تیم شما می پیوندد، همان فرآیند بوت استرپ دردناک را طی کنید. و با وجود تمام تلاش شما، هنوز تفاوت های کوچکی در سیستم هر فرد وجود دارد. اغلب، آنچه روی ماشین یک نفر کار می‌کند روی ماشین دیگری کار نمی‌کند، و هر بار چند ساعت طول می‌کشد تا مسیرهای ابزار اشکال‌زدایی یا نسخه‌های کتابخانه را بفهمیم که تفاوت در کجاست.
شما تصمیم می گیرید که باید سیستم ساخت خود را خودکار کنید. در تئوری، این کار به سادگی تهیه یک کامپیوتر جدید و تنظیم آن برای اجرای اسکریپت ساخت شما هر شب با استفاده از cron است. شما هنوز باید فرآیند راه اندازی دردناک را طی کنید، اما اکنون از مزایای مغز انسان که بتواند مشکلات جزئی را شناسایی و حل کند، ندارید. حالا، هر روز صبح که وارد می‌شوید، می‌بینید که ساخت دیشب شکست خورد، زیرا دیروز یک توسعه‌دهنده تغییری ایجاد کرد که روی سیستم آنها کار کرد اما روی سیستم ساخت خودکار کار نکرد. هر بار این یک راه حل ساده است، اما به قدری اتفاق می افتد که در نهایت هر روز زمان زیادی را صرف کشف و به کارگیری این راه حل های ساده می کنید.
با رشد پروژه، ساختمان ها کندتر و کندتر می شوند. یک روز، در حالی که منتظر تکمیل ساختن هستید، با اندوه به میز کار همکارتان که در تعطیلات است، خیره می شوید و آرزو می کنید که راهی برای استفاده از این همه قدرت محاسباتی هدر رفته وجود داشته باشد.
شما با یک مشکل کلاسیک مقیاس مواجه شده اید. برای یک توسعه‌دهنده که حداکثر یک یا دو هفته روی چند صد خط کد کار می‌کند (که ممکن است تمام تجربه یک توسعه‌دهنده جوان که به تازگی از دانشگاه فارغ‌التحصیل شده باشد)، یک کامپایلر تمام چیزی است که نیاز دارید. اسکریپت ها ممکن است شما را کمی دورتر ببرند. اما به محض اینکه نیاز به هماهنگی بین چندین توسعه‌دهنده و ماشین‌هایشان دارید، حتی یک اسکریپت ساخت عالی نیز کافی نیست، زیرا توضیح تفاوت‌های جزئی در آن ماشین‌ها بسیار دشوار می‌شود. در این مرحله، این رویکرد ساده از بین می رود و زمان سرمایه گذاری در یک سیستم ساخت واقعی فرا رسیده است.