جنکینز چیست؟ سرور CI توضیح داد

جنکینز یک راه ساده برای راه اندازی یکپارچه سازی مداوم و محیط تحویل مداوم برای تقریباً هر ترکیبی از زبان ها و مخازن کد منبع ارائه می دهد.

• هادسون و جنکینز
• اتوماسیون جنکینز
• نحوه عملکرد جنکینز
• افزونه‌های جنکینز
• خط لوله جنکینز
• اقیانوس آبی، رابط کاربری گرافیکی جنکینز
• Jenkins Docker
• چرا از جنکینز استفاده کنیم؟
• جنکینز برای CI/CD

Jenkins یک راه ساده برای راه‌اندازی یک محیط پیوسته یا تحویل پیوسته (CI/CD) برای تقریباً هر ترکیبی از زبان‌ها و مخازن کد منبع با استفاده از خطوط لوله، و همچنین خودکارسازی سایر توسعه‌های معمول ارائه می‌کند. وظایف در حالی که جنکینز نیاز به ایجاد اسکریپت برای مراحل جداگانه را از بین نمی‌برد، اما روشی سریع‌تر و قوی‌تر برای ادغام کل زنجیره ابزارهای ساخت، آزمایش و استقرار در اختیار شما قرار می‌دهد تا اینکه بتوانید به راحتی خودتان بسازید.

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

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

هادسون و جنکینز

در سال ۲۰۰۴، Kohsuke Kawaguchi یک توسعه دهنده جاوا در Sun Microsystems بود. کاواگوچی از شکستن بیلدها در کار توسعه خود خسته شده بود و می خواست راهی بیابد تا قبل از تسلیم کد به مخزن بداند آیا کد کار می کند یا خیر. بنابراین کاواگوچی یک سرور اتوماسیون در و برای جاوا ساخت تا این کار را ممکن کند، به نام هادسون. هادسون در Sun محبوب شد و به عنوان منبع باز در سایر شرکت ها گسترش یافت.

به‌سرعت تا سال ۲۰۱۱، و اختلاف بین اوراکل (که Sun را خریداری کرده بود) و جامعه منبع باز مستقل هادسون، منجر به تغییر نام، جنکینز. در سال ۲۰۱۴ کاواگوچی مدیر ارشد فناوری CloudBees شد که محصولات تحویل مستمر مبتنی بر جنکینز را ارائه می‌دهد.

هر دو فورک همچنان وجود داشتند، اگرچه جنکینز بسیار فعالتر بود. امروزه پروژه جنکینز همچنان فعال است. وب‌سایت هادسون در ۳۱ ژانویه ۲۰۲۰ بسته شد.

در مارس ۲۰۱۹، بنیاد لینوکس، همراه با CloudBees، Google، و تعدادی از شرکت‌های دیگر، یک بنیاد نرم‌افزار منبع باز جدید به نام بنیاد تحویل مستمر (CDF). مشارکت کنندگان جنکینز تصمیم گرفتند که پروژه آنها باید به این بنیاد جدید بپیوندد. کاواگوچی در آن زمان نوشت که هیچ چیز مهمی برای کاربران تغییر نخواهد کرد.

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

اتوماسیون جنکینز

امروزه، جنکینز با ۱۶۰۰ تا ۱۸۰۰ پلاگین برای پشتیبانی از اتوماسیون انواع وظایف توسعه، پیشرو سرور اتوماسیون منبع باز است. مشکلی که کاواگوچی در ابتدا سعی در حل آن داشت، یکپارچه‌سازی مداوم و تحویل مداوم کد جاوا (یعنی ساختن پروژه‌ها، اجرای آزمایش‌ها، انجام تجزیه و تحلیل کد استاتیک و استقرار) تنها یکی از بسیاری از فرآیندهایی است که افراد با جنکینز آن را خودکار می‌کنند. پلاگین های موجود پنج حوزه را شامل می شوند: پلتفرم ها، رابط کاربری، مدیریت، مدیریت کد منبع، و اغلب، مدیریت ساخت.

نحوه کار جنکینز

Jenkins به عنوان یک بایگانی WAR و به عنوان بسته های نصب کننده برای سیستم عامل های اصلی، به عنوان یک بسته Homebrew، به عنوان یک تصویر Docker و به عنوان کد منبع. جنکینز همچنین از نصب و مقیاس‌گذاری در Kubernetes پشتیبانی می‌کند. کد منبع بیشتر جاوا است، با چند فایل Groovy، Ruby و Antlr.

می‌توانید جنگ جنکینز را به‌صورت مستقل یا به‌عنوان یک سرور در یک سرور برنامه جاوا مانند Tomcat اجرا کنید. در هر صورت، یک رابط کاربری وب ایجاد می‌کند و تماس‌هایی را با REST API خود می‌پذیرد.

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

افزونه های جنکینز

جنکینز پس از نصب به شما امکان می‌دهد لیست افزونه‌های پیش‌فرض را بپذیرید یا افزونه‌های خود را انتخاب کنید.

هنگامی که مجموعه اولیه پلاگین خود را انتخاب کردید، روی دکمه نصب کلیک کنید و جنکینز آنها را اضافه خواهد کرد.

صفحه اصلی جنکینز صف ساخت فعلی و وضعیت اجراکننده را نمایش می‌دهد و پیوندهایی را برای ایجاد موارد جدید (شغل)، مدیریت کاربران، مشاهده تاریخچه ساخت، مدیریت جنکینز، مشاهده نماهای سفارشی و مدیریت اعتبار شما ارائه می‌دهد.

یک مورد جدید جنکینز می تواند یکی از شش نوع کار به اضافه پوشه ای برای سازماندهی موارد باشد.

صفحه مدیریت جنکینز به شما امکان می دهد تا ۱۸ کار مختلف از جمله گزینه باز کردن یک رابط خط فرمان را انجام دهید. با این حال، در این مرحله، باید به خطوط لوله نگاه کنیم، که گردش‌های کاری پیشرفته‌ای هستند که معمولاً توسط اسکریپت‌ها تعریف می‌شوند.

خطوط لوله جنکینز

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

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

خطوط لوله جنکینز می تواند به صورت اعلامی یا اسکریپت باشد. یک خط لوله اعلامی، ساده‌تر از این دو، از نحو سازگار با Groovy استفاده می‌کند — و اگر بخواهید، می‌توانید فایل را با #!groovy شروع کنید تا ویرایشگر کد خود را در آن قرار دهید. جهت درست خط لوله اعلامی با یک بلوک pipeline شروع می شود، یک agent را تعریف می کند، و مراحل را که شامل مراحل قابل اجرا می باشد، تعریف می کند. در مثال سه مرحله ای زیر.

pipeline {
    agent any

    stages {
        stage(‘Build’) {
            steps {
                echo ‘Building..’
            }
        }
        stage(‘Test’) {
            steps {
                echo ‘Testing..’
            }
        }
        stage(‘Deploy’) {
            steps {
                echo ‘Deploying....’
            }
        }
    }
}

pipeline بلوک بیرونی اجباری برای فراخوانی افزونه خط لوله جنکینز است. agent محل اجرای خط لوله را مشخص می کند. any می گوید از هر عامل موجود برای اجرای خط لوله یا مرحله استفاده کنید. یک عامل خاص تر ممکن است یک ظرف را برای استفاده اعلام کند، به عنوان مثال:

agent {
    docker {
        image ‘maven:3-alpine’
        label ‘my-defined-label’
        args  ‘-v /tmp:/tmp’
    }
}

مراحل شامل دنباله ای از یک یا چند دستورالعمل مرحله است. در مثال بالا، سه مرحله Build، Test و Deploy هستند.

گام‌ها کار واقعی را انجام می‌دهند. در مثال بالا مراحل فقط پیام های چاپ شده است. یک مرحله ساخت مفیدتر ممکن است به شکل زیر باشد:

pipeline {
    agent any

    stages {
        stage(‘Build’) {
            steps {
                sh ‘make’
                archiveArtifacts artifacts: ‘**/target/*.jar’, fingerprint: true
            }
        }
    }
}

در اینجا ما make را از یک پوسته فراخوانی می‌کنیم و سپس فایل‌های JAR تولید شده را در بایگانی جنکینز بایگانی می‌کنیم.

بخش post اقداماتی را تعریف می‌کند که در پایان اجرای خط لوله یا مرحله اجرا می‌شوند. می‌توانید از تعدادی بلوک شرطی در بخش پست استفاده کنید: همیشه، تغییر، شکست، موفقیت ، ناپایدار و نقط شد.

برای مثال، Jenkinsfile زیر همیشه JUnit را بعد از مرحله آزمایش اجرا می‌کند، اما فقط در صورت شکست خط لوله، ایمیل ارسال می‌کند.

pipeline {
    agent any
    stages {
        stage(‘Test’) {
            steps {
                sh ‘make check’
            }
        }
    }
    post {
        always {
            junit ‘**/target/*.xml’
        }
        failure {
            mail to: team@example.com, subject: ‘The Pipeline failed :(‘
        }
    }
}

خط لوله اعلامی می تواند بیشتر آنچه را که برای تعریف خطوط لوله نیاز دارید بیان کند و یادگیری آن بسیار ساده تر از نحو خط لوله اسکریپت شده است که یک DSL مبتنی بر Groovy است. خط لوله اسکریپت شده در واقع یک محیط برنامه نویسی کامل است.

برای مقایسه، دو فایل جنکینز زیر کاملاً معادل هستند.

خط لوله اعلامی

pipeline {
    agent { docker ‘node:6.3’ }
    stages {
        stage(‘build’) {
            steps {
                sh ‘npm —version’
            }
        }
    }
}

خط لوله اسکریپت شده

node(‘docker’) {
    checkout scm
    stage(‘Build’) {
        docker.image(‘node:6.3’).inside {
            sh ‘npm —version’
        }
    }
}

اقیانوس آبی، رابط کاربری گرافیکی جنکینز

اگر جدیدترین و بهترین رابط کاربری جنکینز را می‌خواهید، می‌توانید از پلاگین اقیانوس آبی استفاده کنید که یک تجربه گرافیکی کاربر را فراهم می‌کند. می‌توانید افزونه اقیانوس آبی را به نصب Jenkins فعلی خود اضافه کنید یا یک Jenkins/Blue Ocean Docker را اجرا کنید ظرف. با نصب Blue Ocean، منوی اصلی Jenkins شما یک نماد اضافی خواهد داشت:

در صورت تمایل می توانید مستقیماً Blue Ocean را باز کنید. در پوشه /blue در سرور جنکینز قرار دارد. ایجاد خط لوله در اقیانوس آبی کمی گرافیکی تر از جنکینز ساده است:

Jenkins Docker

همانطور که قبلاً اشاره کردم، جنکینز به عنوان تصویر داکر نیز توزیع می‌شود. این فرآیند چیز بیشتری ندارد: هنگامی که نوع مدیر کد منبع (SCM) را انتخاب کردید، یک URL و اعتبارنامه ها را ارائه می دهید، سپس یک خط لوله از یک مخزن ایجاد می کنید یا تمام مخازن سازمان را اسکن می کنید. هر شاخه ای که دارای یک Jenkinsfile باشد یک خط لوله دریافت می کند.

در اینجا من یک تصویر Blue Ocean Docker را اجرا می کنم، که با چند افزونه سرویس Git بیشتر از لیست پیش فرض ارائه دهندگان SCM نصب شده است:

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

همچنین می‌توانید روی شاخه‌ها (بالا) و فعالیت‌ها (پایین) بزرگ‌نمایی کنید:

—

چرا از جنکینز استفاده کنیم؟

افزایه Jenkins Pipeline که ما استفاده می‌کنیم، از یک مورد استفاده از یکپارچه‌سازی مداوم/تحویل مداوم (CICD) پشتیبانی می‌کند، که احتمالاً رایج‌ترین مورد استفاده برای Jenkins است. ملاحظات تخصصی برای برخی موارد استفاده دیگر وجود دارد.

پروژه های جاوا علت وجودی اصلی جنکینز بودند. قبلاً دیده‌ایم که جنکینز از ساختن با Maven پشتیبانی می‌کند. همچنین با Ant، ​​Gradle، JUnit، Nexus و Artifactory کار می‌کند.

اندروید نوعی جاوا را اجرا می‌کند، اما نحوه آزمایش در طیف گسترده‌ای از دستگاه‌های Android را معرفی می‌کند. پلاگین شبیه ساز اندروید به شما اجازه می دهد تا هر تعداد دستگاه شبیه سازی شده را بسازید و آزمایش کنید. افزونه Google Play Publisher به شما امکان می‌دهد ساخت‌ها را به یک کانال آلفا در Google Play برای انتشار یا آزمایش بیشتر در دستگاه‌های واقعی ارسال کنید.

من نمونه‌هایی را نشان داده‌ام که در آنها یک کانتینر Docker را به عنوان عامل خط لوله تعیین کرده‌ایم و در آن جا جنکینز و اقیانوس آبی را در یک ظرف Docker اجرا کردیم. ظرف‌های داکر در محیط جنکینز برای بهبود سرعت، مقیاس‌پذیری و ثبات بسیار مفید هستند.

دو مورد استفاده عمده برای Jenkins و GitHub وجود دارد. یکی از آنها یکپارچه سازی ساخت است که می تواند شامل یک قلاب سرویس برای راه اندازی Jenkins در هر commit به مخزن GitHub شما باشد. مورد دوم استفاده از احراز هویت GitHub برای کنترل دسترسی به Jenkins از طریق OAuth است.

جنکینز علاوه بر جاوا از بسیاری از زبان های دیگر نیز پشتیبانی می کند. برای C/C++، پلاگین هایی برای ضبط خطاها و هشدارها از کنسول، تولید اسکریپت های ساخت با CMake، اجرای تست های واحد و انجام تجزیه و تحلیل کد استاتیک وجود دارد. جنکینز تعدادی ادغام با ابزارهای PHP دارد.

در حالی که نیازی به ساخت کد پایتون نیست (مگر اینکه مثلاً از Cython استفاده می کنید یا یک چرخ پایتون برای نصب ایجاد می کنید) مفید است که جنکینز با ابزارهای آزمایش و گزارش پایتون مانند Nose2 و Pytest ادغام شود. و ابزارهای کیفیت کد مانند Pylint. به طور مشابه، جنکینز با ابزارهای Ruby مانند Rake، Cucumber، Brakeman و CI::Reporter ادغام می شود.

جنکینز برای CI/CD

در مجموع، جنکینز یک راه ساده برای راه‌اندازی یک محیط CI/CD برای تقریباً هر ترکیبی از زبان‌ها و مخازن کد منبع با استفاده از خطوط لوله، و همچنین خودکار کردن تعدادی دیگر از وظایف توسعه معمولی ارائه می‌کند. اگرچه جنکینز نیاز به ایجاد اسکریپت برای مراحل جداگانه را برطرف نمی‌کند، اما راهی سریع‌تر و قوی‌تر برای ادغام کل زنجیره ابزارهای ساخت، آزمایش و استقرار در اختیار شما قرار می‌دهد تا اینکه خودتان به راحتی بسازید.