googlebd2d08236268006b

Continuous Integration

کج فهمی ها و برداشت های اشتباه از دوآپس

کج فهمی ها و برداشت های اشتباه از دوآپس

تصورات اشتباه و کج فهمی ها درباره دوآپس

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

دوآپس چیست ؟

  • آیا دوآپس یک ابزار است ؟
  • آیا دوآپس یک تکنولوژی است ؟
  • آیا دوآپس یک تیم است؟
  • آیا دوآپس فقط یک فرهنگ است؟
  • آیا دوآپس فقط Automation است؟
  • آیا دوآپس فقط یک عنوان شغلی است؟
  • آیا دوآپس فقط یک سبک تفکر است؟
  • آیا دوآپس فقط Continuous Delivery است؟
  • آیا دوآپس به معنی حذف Operation است ؟
  • آیا دوآپس فقط به توسعه و عملیات (Dev و Ops) محدود می شود ؟
  • آیا دوآپس به همه چیز در همه جا مربوط می شود ؟

در ادامه پاسخ سوالات را خواهید یافت.

ادامه مطلب را در سایت HiDevOps.com بخوانید 

 

Continuous Integration چیست؟

Continuous Integration چیست؟

به فرایند ادغام یکپارچه کد ها و بیلد کردن پروژه ها و اجرای unit test ها به صورت اتوماتیک، Continuous Integration یا CI می گویند. با اجرای CI، با اعمال یک تغییر در سورس کد و اضافه شدن آن به source control، یک بیلد اتوماتیک را به راه می افتد تا بوسیله آن، آخرین نسخه کدها از مخزن کد استخراج و بیلد شود و unit test های آن اجرا شود، در واقع با این کار یک ارزیابی کلی از سلامت کدها انجام شود. این کار معمولا چندین بار در یک روز انجام می شود.

در نبود Continuous Integration چه اتفاقی می افتد ؟
Continuous Integration چه کمکی به ما می کند ؟

 

ادامه مطلب را از سایت HiDevOps.com بخوانید (لینک زیر)

https://goo.gl/ukG5sQ

 

Invoke MsDeploy and MsBuild on Powershell

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

مایکروسافت برای بیلد و انتشار نرم افزار، ابزارهای جداگانه ای داره که سعی کرده توی tfs و در قسمت ساخت بیلد های اتوماتیک، اونارو یکجا مورد استفاده قرار بده. اما هنوز کمبودهایی داره و توی پروژه های جامع سازمانی پاسخگوی تمام نیاز ها نیست یا به دردسرش نمی ارزه که ازش استفاده کنین.

بعضی مواقع ترجیح بر اینه که از دستورات خط فرمان ویندوز استفاده کنیم. که میتونیم از  command-prompt یا powershell استفاده کنیم. از اونجایی که powershell بسیار پیشرفته تر از command-prompt هست، ترجیح بر استفاده از powershell یا دستورات cmdlet هست.
دستوراتی مثل start یا stop یا install و uninstall کردن یک ویندوز سرویس، کپی کردن فایل و کارهای را میشه از طریق powershell انجام داد.

وقتی powershell را انتخاب میکنیم، دیگه کار جالبی نیست که یک سری کارها را با powershell و یک سری دیگه را با cmd انجام بدیم و اصلا منطقی هم نیست.
MsBuild وMsDeploy دو تا از ابزارهایی هستن که توی Automatic-Deployment زیاد ازش استفاده میشه. به طور پیش فرض، این برنامه ها از طریق command-prompt اجرا میشن. با یک جستجوی ساده توی اینترنت میشه راهی پیدا کرد که این برنامه ها را از طریق powershell اجرا کرد.

برای راحت تر کردن این کار میتونیم از Moduleهای powershell استفاده کنیم.
یک ماژول برای اجرای MsBuild توی این آدرس پیدا کردم.  https://invokemsbuild.codeplex.com/
اما برای MsDeploy ماژولی پیدا نشد که خودم دست به کار شدم یکی نوشتم که از این آدرس میتونین دریافت کنین. https://github.com/omids20m/Invoke-MsDeploy-PowerShell-Module

امیدوارم این مطلب مورد توجه شما دوستان قرار گرفته باشه 🙂

چالش های انتشار خودکار نرم افزارهای جامع سازمانی

چالش های انتشار خودکار نرم افزارهای جامع سازمانی

Deployment Challenges in Enterprise Scenarios

سلام

یه مدتی هست که درگیر Deployment شدم. گفتم بد نیست توی این زمینه یه ذره بنویسم.

همه ی کسانی که برنامه نویسی میکنند خواه نا خواه درگیر مقوله ی Deployment یا Publish نرم افزار میشن.

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

کاری که قرار شد من برای اون Automatic-Deployment را راه اندازی کنم شامل بیش از ۲۰ تا پروژه در زمینه ی راهکارهای جامع مالی کارگزاری بورس بود که شامل یک سری Web-Application و Windows-Service میشد. هدف ما این بود که بتوانیم به صورت زمان بندی شده (مثلا هر روز یکبار) یا با یک کلیک، کل این پروژه ها را در جاهای مختلفی که قبلا تعریف شده منتشر (Publish) کنیم.

شاید بعدا در این رابطه بیشتر بنویسم.اما توی این پست فقط سعی دارم به چالش هایی که در مبحث Enterprise-WebApplication-Deployment باهاش مواجه هستیم، اشاره ای داشته باشم:

  1. پروژه ها باید در محیط های مختلفی که از نظر زیر ساخت سخت افزاری و نرم افزاری و امنیتی با هم متفاوت هستند و هر کدام کانفیگ (پیکربندی) خاص خود را دارند منتشر و نصب شوند. برای مثال: developer or test environments, staging-platforms, and production-servers
  2. باید بتوانیم پروژه های مرتبط به هم را در یک مرحله (مثلا با یک کلیک) یا به صورت اتوماتیک و زمان بندی شده (مثلا هر روز) منتشر کنیم.
  3. باید بتوانیم هر بار که کدی به Source-Control اضافه میشه، کل نرم افزارهای وب و ویندوز-سرویس ها را publish کنیم.
  4. باید بتوانیم در هر لحظه، هر نسخه دلخواه از نرم افزار را روی یکی از سرورها publish کنیم.
  5. باید بتوانیم بدون نیاز به ابزارهای توسعه، مثل Visual Studio، توسط شخصی بدون داشتن دانش مربوط به توسعه نرم افزار و با ساده ترین روش ممکن کار انتشار را انجام دهیم. بهترین روش هم از طریق وب است.
  6. باید بتوانیم بر روند انتشار و تنظیم متغیرهای انتشار، کنترل داشته باشیم.
  7. پایگاه داده ها باید بدون از دست دادن داده های قبلی به طور اتوماتیک Update به روز رسانی شوند.
  8. باید بتوانیم قبل از پابلیش و بعد از آن یک سری Command روی سرورها اجرا کنیم (مثلا Start and Stop Windows-Service) و همچنین بتوانیم برخی از فایل ها را اضافه یا حذف کنیم ( مثلا اضافه کردن فایل app_offline.htm قبل از Publish و حذف آن بعد از Publish).