googlebd2d08236268006b

CD

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

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

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

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

دوآپس چیست ؟

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

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

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

 

DevOps چیست؟ چرا آن را اجرا کنیم؟

DevOps چیست؟ چرا آن را اجرا کنیم؟

DevOps یا دِوآپس، مجموعه ای از روش ها، فرایند ها و ابزارهایی است که با تمرکز بر ارتباطات و همکاری بین تیم های توسعه، تضمین کیفیت و عملیات، ارزش های تولید شده را به روش سریع و مداوم به مشتریان نهایی می رساند. ادغام کلمات اختصاری “Dev” و “Ops” به این

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

بیشتر

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

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

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

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

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

 

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

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

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

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

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