googlebd2d08236268006b

Continuous Delivery

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

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

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

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

دوآپس چیست ؟

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

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

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

 

دوآپس به زبان ساده چیست ؟ | DevOps به زبان ساده چیست ؟

DevOps چیست ؟ | دوآپس چیست و چرا مطرح شد ؟

سال های متمادی در شرکت های توسعه نرم افزار، دو تیم وجود داشتند که هدف آنها کاملا متضاد بود، تیم توسعه (Development) و تیم عملیات (Operation). هدف تیم توسعه ساخت ویژگی های جدید بر روی محصول و در نتیجه تغییرات زیاد روی آن بود، اما هدف تیم عملیات، ثابت نگه داشتن وضعیت موجود سرویس ها برای پایداری بیشتر آن ها بود. بدین ترتیب دیواری بین این دو تیم وجود داشت.
به مرور زمان تیم های توسعه به روش های چابک برای تولید نرم افزار روی آوردند که تعامل همیشگی با مشتریري، اعمال تغییرات، و اضافه کردن ویژگی های جدید بر اساس نظر مشتریان قسمتی از این روش های چابک بود.
اما دیوار بین دو تیم Dev و Ops باعث می شد تا عملیاتی کردن ویژگی های جدید توسعه داده شده و تغییرات، به اندازه کافی چابک نباشد. تمرکز روش های چابک توسعه نرم افزار، بر توسعه و تولید نرم افزار بود و کمتر به موضوعاتی مثل استقرار (Deployment) و عملیات (Operation) توجه می کرد.

به دنبال این محدودیت هامفهومی به است دوآپس (DevOps) مطرح شد و به دنبال این بود که دیوار بین تیم های Dev و Ops را از بین ببرد و با تمرکز بر افزایش تعاملات بین تیمی، موجب افزایش سرعت تحویل ارزش به مشتری شود. پس دوآپس به دنبال این است که ارزش های ایجاد شده در نرم افزار را خیلی سریعتر به دست مشتری برساند

دوآپس چیست ؟ DevOps چیست ؟

 

چرا دواپس مهم شد ؟

ادامه مطلب در اینجا دنبال کنید : “دوآپس به زبان ساده چیست ؟

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).