لذت برنامه نویسی: نحوه کار ما با jenkins

اینم یه تجربه پراکنده دیگه!

خب حدودا سه سال قبل من از جای خالی continues integration نوشتم. حالا حدود بعد از سه سال میخوام دوباره به موضوع رجوع کنم و درباره jenkins بنویسم

توی این سه سال اتفاقات زیادی افتاده. ما روند build رو با استفاده از cmake بهتر کردیم. یادگرفتیم که چی به چیه. حدودا انتهای سال قبل بود که توی شرکت منابع و علم کافی برای پیاده‌سازی روند ci بوجود اومد و ما شروع کردیم به استفاده از jenkins.

نصب و راه‌اندازی jenkins به نسبت آسون و راحت بود. کاری که jenkins برای ما میکرد این بود که به یه دلیلی(بخونید ماشه) شروع به کامپایل کد میکرد. روند کامپایل هم آسون بود. یعنی اینکه یه سری پروژه معمول رو میشناسه مثل cmake, make, gradle, maven داره که کار رو راحت میکنه

ما اول به یه پروژه معمولی که بصورت ساعتی اجرا میشد شروع کردیم فقط نکتش اینه که ما با سخت‌افزارهای مختلف کار میکنیم و این تنها برای یکی از سخت‌افزارهامون کار میکرد. بعدش یه پروژه معمولی دیگه اضافه کردم که با cppcheck کار static analysis رو روی کدمون بصورت ساعتی انجام میداد.

در مرحله بعد با استفاده امکانی از jenkins pipeline تمامی سخت‌افزارها رو باهم کامپایل کردیم و cppcheck هم به عنوان یک مرحله از این خط لوله ما انتخاب شد.

در قدم بعدی هم این ماجرا رو به git وصل کردیم و به ازای هر کامیت یا هر درخواست بررسی که روی کدمون انجام میدیم شروع به کامپایل میکنه و ما میدونیم که دیگه تغییرمون چیزی رو خراب نمیکنه.

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

فعلا همین!

لذت برنامه نویسی: نوشته‌های من در مورد git

اینم یه تجربه پراکنده دیگه!

من مدتی میشه که با مجله هایو همکاری دوستانه دارم و سعی میکنم مطالبی که عمومی تره رو اونجا بنویسم. حالا توی این مدت من ۳ تا مقاله در مورد git نوشتم که اونجا منتشر شده. پیشنهاد میکنم اگه دوست داشتید برید و بهش سر بزنید

لیست مقالات از این قراره

همین!

پ.ن. خوشحال میشم به مابقی نوشته‌های من توی اونجا سر بزنید.

Gogs Logo

چرا لینوکس را دوست دارم: داشتن github در خانه با Gogs

اینم یه تجربه پراکنده دیگه!

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

یکی از بامزه ترین اونها نرم‌افزاری به نام Gogs هست که سعی کرده با استفاده از ویژگی‌های golang یک راه‌حل برای میزبانی git شبیه به github ایجاد کنه. نصب کردن این راه‌حل به شدت ساده است چون کلا نصب پکیج‌های golang ساده است. اما بزرگترین مشکلی که برای ما وجود داره تحریم از سمت گوگل هست که شما باید به نحوی اون رو برطرف کنید. این سرویس اونقدر قابل اطمینان بوده که آدم‌هایی پیدا شدن و با تغییر اندکی از اون به عنوان یک کپی github استفاده می‌کنند. اسم اون سایت notabug هست و پیشنهاد می‌کنم ببینیدش.

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

همین!

بروزرسانی: با توجه به اینکه فرود عزیر تجربه contribute کردن به این پروژه رو داشتن، گفتن که نحوه اداره این پروژه خیلی بده و به همین خاطر یک fork از این برنامه به اسم gitea بوجود اومده که انگار بهتر مدیریت میشه. و اینکه کلا توجه داشته باشید که تخم مرغ‌هاتون رو توی یک سبد نگذارید!

لذت برنامه نویسی: مهاجرت از svn به git

اینم یه تجربه پراکنده دیگه!

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

به علت پشتیانی git از svn این مهاجرت تقریبا آسونه و آموزش‌های زیادی مثل این و این توی اینترنت وجود داره. مراحلش بدون جزئیات ایناست:

  1. ساختن یک فایل mapping از یوزرهای svn به یوزهای git
  2. clone  کردن از svn به git با استفاده از دستور git svn
  3. ساختن یک ریپوزیتوری جدید که دیگه چیزی از svn توش نیست با ریپوزیتوری ساخته شده در مرحله ۲
  4. فرستادن این ریپوزتوری جدید روی سرور

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

همین!

لذت برنامه نویسی! نگهداری و مدیریت نسخه‌ها و آنچه گذشت!

اینم یه تجربه پراکنده دیگه!

من مدت‌های زیادی هست که برنامه نویسی می‌کنم و توی این مدت سعی کردم در مورد تکنیک‌های و شگردهایی که در دنیا برای برنامه‌نویسی استفاده میشه اطلاع کسب کنم. از اولین چیزهایی که باهاش آشنا شدم سیستم‌های کنترل و مدیریت نسخه یا همون Version Control System هست. حالا میخواستم یکم بیشتر در این مورد توضیح بدم چون دیدم که خیلی‌ها علاوه برا اینکه از این ابزارهای استفاده نمی‌کنن اعتقادی هم به استفاده ازش ندارن.

بصورت ساده این سیستم‌های به روش‌های مختلفی نسخه‌های مختلف فایل رو نگهداری می‌کنند یا «آنچه گذشت» رو مدیریت می‌کنند. این ابزار برای برنامه نویس‌ها و تقریبا هر کسی  که یه سری فایل رو بصورت مداوم بروز رسانی می‌کنه (مثلا متن یک قرار داد، یا یک مقاله علمی و …) مهمه. وقتی کار جدی می‌شه خیلی وقت‌ها به این نیاز میشه که بدونیم:

  • تغییرات این نسخه نسبت به نسخه قبل چیه؟ یا بدونیم که قبلا چی بود و الان چی هست.
  • در صورتی که این فایل‌ها توسط بیشتر از یک نفر دارن مورد ویرایش قرار می‌گیرن همیشه این سوال وجود داره که آخرین نسخه فایل چیه؟
  • سوال بعدی که پیش میاد اینه که چه کسی مسئول اضافه کردن این بخش به فایل(به عنوان مثال قرار داد) هست که بعدا خودش تصحیحش کنه.

اما برای استفاده از این سیستم‌ها همیشه یه مقاومتی وجود داره که دلایل معمولش اینا هستن:

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

اگه بخوام اسمی از این ابزارها بیارم لیستشون خیلی زیاده و دعوا هم سر اینکه کدوم بهتره زیادن. مثلا دوستانی که با ابزارهای مایکروسافت کار میکنن TFS رو با دنیا عوض نمی‌کنن. دوستانی که در محیط لینوکس برنامه نویسی میکنن و یکم هم قدیمی هستن از SVN تا خون در رگ دارن دفاع میکنن. و اونایی که «اوپن سور باز» هستن هم GIT رو میپرستن. اما دقت داشته باشید که از دید من مهم‌ترین قسمت اینه که یکی از این سیستم‌ها در محیط شما مورد استفاده قرار بگیره و اینکه اون ابزاری رو انتخاب کنید که اکثریت آدم‌ها نسبت بهش نظر خاصی ندارن و یا با اون سیستم به اصطلاح «راحتن».

اما لیست برنامه‌های کنترل نسخه اینا هستن:

  • Team Foundation Server: این برنامه توسط مایکروسافت تولید میشه که یک مجموعه کامل مدیریت پروژه نرم‌افزاریه که شامل برنامه کنترل نسخه هم هست. این نرم افزار جزء نرم‌افزارهای مدیریت نسخه متمرکزه.
  • GIT: این سیستم که توسط لینوس توروالدز نویسنده هسته لینوکس برای مدیریت کدهای هسته لینوکس مورد استفاده قرار گرفته. این سیستم جز سیستم‌های مدیریت نسخه غیر متمرکزه
  • CVS: تقریبا قدیمی ترین برنامه کنترل نسخه متمرکزیه که من میشناسم
  • SVN: یک سیستم مدیریت نسخه متمرکز است که طراحی شده تا با CVS همخوانی داشته باشه و اشکالات این سیستم رو رفع کنه
  • HG: هم تقریبا همزمان با GIT توسعه پیدا کرده و هدفش این بوده که سیستم مدیریت نسخه غیر متمرکز باشه.
  • Bazaar: سیستم کنترل نسخه غیر متمرکزه که توسط شرکت canonical پشتیبانی میشه

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

همین