ডিওঅপস কি সাশ পণ্য যুক্ত সংস্থাগুলিতে সীমাবদ্ধ?


26

ডিওওপিএস বর্ণনা করার পদ্ধতিগুলি যেমন অবিচ্ছিন্ন সরবরাহ, অটোমেশন ইত্যাদি এমন পণ্যগুলির সাথে প্রাসঙ্গিক যা ধারাবাহিক পরিষেবা সরবরাহ করে, যেমন সাএস পণ্যগুলি।

উদাহরণস্বরূপ, একটি সফ্টওয়্যার ডেভলপমেন্ট সংস্থা যা বেশিরভাগ অন্যান্য ক্লায়েন্টদের জন্য প্রকল্প করে তা প্রকল্প শেষ হওয়ার পরে কখনও এগুলি বজায় রাখা যায় না। এবং ক্লায়েন্ট প্রকল্পগুলি অন্য ক্লায়েন্টদের সাথে ভাগ করা হয় না, কারণ এটি অপ্রাসঙ্গিক।

এমনকি ডেভঅপস এমনকি এমন সংস্থাগুলির ক্ষেত্রেও কী প্রযোজ্য যেগুলি এক-অফসযুক্ত একাধিক প্রকল্প বিকাশ করে? ডিভোপস অনুশীলনগুলি এক্ষেত্রে কি প্রয়োগ হয়?

উত্তর:


32

একেবারে না!

ডিভোপস আরও দক্ষ হওয়ার জন্য traditionalতিহ্যবাহী সিলোগুলি (বিভাগগুলি) ভেঙে ফেলার বিষয়ে।

দলগুলির মধ্যে আরও ভাল যোগাযোগ, উন্নত দৃশ্যমানতা এবং নির্ভরযোগ্য এবং স্বয়ংক্রিয় প্রক্রিয়া একটি উন্নত পণ্য অর্জনের উপায়।

আমি একটি বড় মিডিয়া সংস্থার জন্য কাজ করতাম যেখানে আমরা একটি অভ্যন্তরীণ সরঞ্জাম সমর্থন করব এবং জনসাধারণের মুখোমুখি ওয়েবসাইটগুলি বিকাশ করব।

আমাদের ক্ষেত্রে ডিভোপসের সুবিধাগুলি নিম্নলিখিত ছিল:

  • অবিচ্ছিন্ন বিল্ডিংয়ের মাধ্যমে, আমরা যদি তাদের কোডটিতে ইন্টিগ্রেশন থাকে বা সমস্যা তৈরি করে থাকে তবে পরে উন্নয়নের দলটিকে আগে বলি। তারা সমস্যাগুলি সমাধান করতে পারে যখন তাদের মন এখনও ঠিক করা কোডের অংশে রয়েছে।
  • অবিচ্ছিন্ন পরীক্ষা এবং বিতরণের মাধ্যমে (কিউএ), আমরা কিউএ টিমকে এর আগে সমস্যাগুলি খুঁজে পেতে এবং তাদের আগে রিপোর্ট করতে সক্ষম করেছিলাম। এটি ত্রুটিগুলি খুঁজে পেতে এবং সংশোধন করার পাশাপাশি এই তদন্তের জটিলতা হ্রাস করতে সময় কমিয়েছে।
  • লগ সংগ্রহ এবং সংগৃহীত সরঞ্জামগুলির সাহায্যে আমরা বিকাশকারীদের এমন কিছুতে অ্যাক্সেস দিয়েছিলাম যা তারা সাধারণত দেখেনি (তারা ডিবাগারগুলিতে খুব আগ্রহী ছিল :) - লগগুলি কীভাবে দেখানো হয় এবং অন্যান্য দলগুলি কীভাবে ব্যবহার করে তা বোঝার ফলে লগগুলির সামগ্রিক মান উন্নত হয় understanding
  • আমরা প্রায়শই তথ্য ভাগ করে নিয়েছিলাম এবং দলগুলির মধ্যে জ্ঞান ভাগ করে নেওয়ার জন্য ডকুমেন্টেশন তৈরি করেছি, দেয়ালগুলি ভেঙে দেওয়ার চেষ্টা করেছি। অপ্সের প্রয়োজনীয়তাগুলি বোঝার মাধ্যমে আমরা কোনও অ্যাপ্লিকেশন বুটস্ট্র্যাপ করার সময় (যেখানে / কীভাবে সম্পত্তি পরিচালনা করতে হবে ইত্যাদি) সর্বদা কী মনে রাখা উচিত তার জন্য আমরা কয়েকটি গাইড তৈরি করি। দেবের বাস্তবতা (আরও বৈশিষ্ট্যগুলির কোড, দ্রুত, গোগোগো!) বুঝতে পেরে আমরা অপ্সকে সার্ভার এবং ক্লাস্টার তৈরি করতে সক্ষম করেছিলাম যা দেবের প্রয়োজনের সাথে আরও উপযুক্ত।
  • মোতায়েনের সামগ্রিক গুণমানও খুব উন্নত হয়েছিল। মোতায়েনগুলি আমাদের টিম দ্বারা পরিচালিত হয়েছিল, সুতরাং আমাদের ওপস এবং দেব উভয়ের উপর নিখুঁত দৃশ্যমানতা ছিল। এটি "কোড হ্যান্ড-অফ" সম্পর্কিত অনেকগুলি সমস্যা সরিয়ে নিয়েছে যেখানে দেব "এটি ইনস্টল করুন!" বলে অ্যাপগুলিকে একটি প্যাকেজ এবং এক পৃষ্ঠার নথি হস্তান্তর করবে।

সামগ্রিকভাবে, আমি এটাই বলব যে আপনি যদি নিজের উত্পাদন পরিবেশকে প্রতিদিন একবার বা মাসে একবার আপডেট করে থাকেন এবং আপনার কতজন গ্রাহক বা আপনার ব্যবসায়ের মডেল নির্বিশেষে প্রতিটি উদ্যোগ উন্নত যোগাযোগ, আরও ভাল সরঞ্জাম, আরও ভাল দৃশ্যমানতা, দ্রুত প্রতিক্রিয়া, প্রভৃতি


1
নিশ্চয় DevOps কার্যত কোনো SW উন্নয়ন সংস্থা, এমনকি প্রতি বছর পাবলিক রিলিজ শুধু মুষ্টিমেয় দিয়ে বড় embeeded পণ্য প্রয়োগ করা যেতে পারে - একটানা বিতরণ ব্যবহার করে ভিতরে তাদের উন্নয়ন পাইপলাইন তারা এখনও কিছু DevOps বেনিফিট কাটা করতে পারেন: ভালো মানের, খরচ কমানো, পূর্বাভাসযোগ্যতা ইত্যাদি ইত্যাদি
ড্যান কর্নিলিস্কু

উত্তরটি একটি সাআসকে স্মরণ করিয়ে দেয়, কীভাবে একটি নন-সাশ পণ্য বা পরিষেবা এই অনুশীলনগুলি থেকে উপকৃত হতে পারে তা সত্যই ব্যাখ্যা করে না।
ইভজেনি

আমি যে পণ্যগুলিতে কাজ করছিলাম সেগুলি সস (একেবারে বিপরীত) ছিল না। তবে যৌক্তিকতা একই থাকে, আপনি সাস হন বা না থাকুন এ বিষয়ে কিছু যায় আসে না, ডিভস অপ্রচলিত উপায়ে পণ্যটি উন্নত করার চেষ্টা করে। আমি আমাদের দামের মডেল বা অফার সম্পর্কে কিছুই জানতে পারি না, এটি এতটা তত্ক্ষণিকতা তৈরি করবে না।
আলেকজান্দ্রি

13

আমার দল এবং আমি "ওয়ান-অফস" বিকাশের জন্য দায়বদ্ধ, পণ্যগুলি যা একবার শেষ হয়ে যায় ক্লায়েন্টকে রক্ষণাবেক্ষণের জন্য দেওয়া হয় বা কিছু ক্ষেত্রে আমাদের দ্বারা ফি বাবদ পরিচালিত হয়।

আমাদের ক্লায়েন্টদের কাছ থেকে ধ্রুবক প্রতিক্রিয়া হ্যান্ডেল করার জন্য আমাদের এখনও নির্ভরযোগ্য এবং চালিত প্রমাণিত কিছু পাঠানো নিশ্চিত করতে আমাদের এখনও একটি শক্ত বিকাশ পাইপলাইন বজায় রাখতে হবে।

যদিও ক্লায়েন্টটি ডিভোপস (বেশিরভাগ ক্ষেত্রে) যত্ন করে না, তবুও এটি আমাদের জন্য সহায়ক। ডিভোপসের সাহায্যে আমরা দ্রুত নতুন বিল্ডগুলি ধাক্কা দিতে পারি, যাতে ক্লায়েন্টরা কয়েক মিনিটের মধ্যেই নয় মিনিটের মধ্যে প্রতিক্রিয়া দেখতে পারে এবং জেনকিনস / ট্র্যাভিসের মাধ্যমে আমাদের পরীক্ষার মাধ্যমে আমরা কোনও ত্রুটি / বাগগুলি ধরতে সক্ষম হয়েছি।

আমাদের স্থাপনার কৌশলগুলি প্রকল্পগুলি জুড়ে একইরূপে তা নিশ্চিত করতে আমরা আমাদের অ্যাপ্লিকেশনগুলিকে ধারককরণের দিকে মনোনিবেশ করি। ডকার ব্যবহার করে, আমরা সহজেই আমাদের ক্লায়েন্টদের কাছে অ্যাপ্লিকেশনটি সহজেই বন্ধ করতে সক্ষম হয়েছি।

ডিওঅপস দ্বারা সংরক্ষিত ব্যয় নির্ধারণ করা শক্ত। পাইপলাইনের জন্য আমরা যে সফটওয়্যারটি ব্যবহার করতে চাই তার আকারে আমাদের অতিরিক্ত ব্যয় হয় (ট্র্যাভিস, জেনকিনস, পুতুল, আপনার কী আছে) তবে আমরা বাগগুলি ঠিক করে / ক্লায়েন্টদের দ্রুত প্রতিক্রিয়া জানিয়ে সময় এবং অর্থ সাশ্রয় করি। আমাদের দ্রুত প্রতিক্রিয়ার সময়টি আমাদের ওয়ালেটগুলিকে খুশি রাখে এবং আমাদের গ্রাহকদের সুখী রাখে।


কেন এটি গুরুত্বপূর্ণ তা আপনি কিছু কারণ এবং সুবিধা সরবরাহ করতে পারেন? ক্লায়েন্টরা কি আসলে আপনার পাইপলাইন, বা কেবলমাত্র শেষের প্রকল্পের প্রতিশ্রুত তারিখে এবং তাদের যে মূল্য দিতে হবে সেগুলি যত্ন করে? এই সমস্ত "ডিভস-ওয়াই" জিনিস না করে আপনি কি ব্যয় হ্রাস করতে পারবেন? আপনি কি আরও বেশি ঘন্টা কোনও প্রকল্পে এই জিনিসগুলি না করে আরও বেশি সময় পেতে পারেন এবং প্রকল্পগুলির জন্য বেশি অর্থ পেতে পারেন (যেহেতু এটি দীর্ঘ)?
ইভজিনি

1
@ অ্যাভজেনি ডেভসগুলি আমার উত্তরটিতে ব্যাখ্যা করার কারণে কারণ সময় এবং বাজেটে প্রকল্পটি শেষ করতে সহায়তা করে। ডিভোপস কেটে, আপনি যে সুবিধাগুলি আমার ব্যাখ্যা করেছেন তাও কাটতে পারবেন। বিল্ডিং এবং পরীক্ষা প্রায়শই বাজেটে এবং সময়মতো থাকতে সহায়তা করে। পরে ত্রুটিটি খুঁজে পেতে আরও বেশি অর্থ ব্যয় হয় এবং এটি ঠিক করতে আরও সময় লাগে, এটি বারবার প্রমাণিত হয়েছে। ক্লায়েন্ট পাইপলাইনটির বিষয়ে চিন্তা করে না, তবে আপনি তার প্রতিক্রিয়ার জন্য যত বেশি অপেক্ষা করবেন, পুনর্লিখনটি তত বেশি ব্যয়বহুল এবং সময়সাপেক্ষ হবে।
আলেকজান্দ্রি

এটি কি কেবল চতুর সফটওয়্যার দেব নয়?
ইভজিনি

@ এ্যাভজেনি আমি আমার উত্তরটি পরিষ্কার করতে আপডেট করেছি। আমরা ব্যবহার তত্পর না, কিন্তু বলতে চাচ্ছি যে না আমরা DevOps মানসিকতা থাকতে পারে না ..
কচ্ছপ

1
@ এ্যাজজেনি আপনি সম্ভবত আপনার ইউনিট পরীক্ষা এবং গ্রহণযোগ্যতা পরীক্ষা না চালিয়ে কিছু সাশ্রয় করতে পারেন, তবে এটি প্রযুক্তিগত tণ তৈরি করে যা ডিভোপস অ্যান্টি-প্যাটার্ন। আপনি কয়েক সপ্তাহ বা মাসের জন্য এটি থেকে দূরে সরে যেতে পারেন, তবে আপনি শীঘ্রই শেষ করতে পারেন (সম্ভবত) জঞ্জাল বজায় রাখা একটি কঠিন যা পরীক্ষা করা অসম্ভব।
স্টিভ বাটন

3

আমি সংকুচিত-মোড়ানো পণ্য হিসাবে সম্পূর্ণরূপে ইনস্টলড এবং সমর্থিত ডিপ্লয়েমেন্ট এবং ডিভাইসগুলিতে এম্বেড কোড হিসাবে সফটওয়্যার তৈরির সংস্থাগুলির পক্ষে কাজ করেছি। এই সমস্ত সংস্থায় ডিভোপস উন্নয়নের জন্য প্রয়োজনীয় সহায়তা সরবরাহ করে:

  • সংকলক, গ্রন্থাগার এবং অন্যান্য বিল্ড সরঞ্জামগুলির পরিচিত, নিয়ন্ত্রিত কনফিগারেশন সহ সফ্টওয়্যারগুলির স্বয়ংক্রিয়, পুনরুত্পাদনযোগ্য বিল্ড।
  • রিগ্রেশন পরীক্ষার জন্য এবং নতুন কার্যকারিতা পরীক্ষার জন্য অটোমেটেড, পুনরাবৃত্তযোগ্য সিস্টেম পরীক্ষা।
  • অন্যান্য স্বয়ংক্রিয় এবং নিয়মিত ক্রিয়া (উদাহরণস্বরূপ, সমস্ত সমর্থিত ভাষাগুলিতে ক্রমাগত আপডেট হওয়া স্যাম্পল স্ক্রিন শটগুলি অনুবাদকদের যাচাই করার জন্য এবং প্রযুক্তিগত লেখকদের ব্যবহারকারী ম্যানুয়ালগুলিতে অন্তর্ভুক্ত করার জন্য)।

সমস্ত ক্ষেত্রে, এগুলি এমন জিনিস যা পৃথক বিকাশকারীরা ওয়ান-অফ হিসাবে করতে পারে তবে এটি বিকাশকারী সময়ের উপযুক্ত ব্যবহার হবে না, বা স্বয়ংক্রিয় বিল্ডগুলির কনফিগারেশন নিয়ন্ত্রণের একই নিশ্চয়তা থাকবে না।


অটোমেশন ডিওপস নয়। নীচে ডেভিড বকের উত্তর হিসাবে একই মন্তব্যগুলি শেষ অবধি (দুঃখিত, আমার মন্তব্যটি আমি হ্রাস করার সময় হারিয়ে গিয়েছিলাম, কেবল এটি লক্ষ্য করা হয়েছে)
তেনসাইবাই

3

সফ্টওয়্যারটির বিকাশ ও বাস্তবায়নের জন্য আগে বিভাগগুলির মধ্যে গভীর সংহতকরণের প্রয়োজন ছিল না। তবে আজকের জন্য সমস্ত বিভাগকে (বিকাশ, আইটি অপারেশন, গুণগত মান ইত্যাদি) নিবিড়ভাবে সহযোগিতা করা প্রয়োজন।

বিকাশকারীদের জন্য, পরিবর্তনের অর্থ তারা যা পায়। আধুনিক বিশ্বের সাথে মেলে ব্যবসায়ের সর্বদা পরিবর্তন প্রয়োজন needs এই বোঝাপড়াটি বিকাশকারীদের সর্বাধিক সম্ভব সংখ্যক পরিবর্তন আনতে ধাক্কা দেয়। আইটি পেশাদারদের একটি আলাদা বোঝাপড়া রয়েছে, যার মধ্যে পরিবর্তন ক্ষতি। তাদের প্রত্যেকে মনে করে যে এটি সঠিকভাবে কাজ করে, ব্যবসায়ের উপকার করে। সত্যই, যদি আমরা তাদের আলাদাভাবে বিবেচনা করি তবে তারা উভয়ই ঠিক।

সমস্ত কর্মীদের অবশ্যই বুঝতে হবে যে তারা একটি একক প্রক্রিয়ার অংশ। ডিভোপস চিন্তাভাবনা জাগ্রত করে, যার ফলে এটি উপলব্ধি করা সম্ভব হয় যে প্রত্যেকের ব্যক্তিগত সিদ্ধান্ত এবং ক্রিয়াগুলি একটিমাত্র লক্ষ্য অর্জনের দিকে পরিচালিত হওয়া উচিত। এবং সাফল্য পুরো উন্নয়ন-থেকে-বিতরণ চক্রের তুলনায় পরিমাপ করা উচিত, পৃথক ভূমিকার সাফল্য থেকে নয়। বিকাশকারী এবং রক্ষণাবেক্ষণ বিশেষজ্ঞদের মধ্যে ঘনিষ্ঠ সহযোগিতার ফলস্বরূপ, ইঞ্জিনিয়ারদের একটি নতুন প্রজন্ম গঠিত হয়, যা উভয় শাখার সেরা অর্জন করে এবং ব্যবহারকারীর সুবিধার জন্য তাদের একত্রিত করে। এটি উন্নয়ন, কনফিগারেশন পরিচালনা, ডাটাবেস পরিচালনা, পরীক্ষা এবং অবকাঠামো পরিচালনার অভিজ্ঞতার সাথে ক্রস-ফাংশনাল দলগুলির উপস্থিতিতে প্রকাশিত হয়।

সুতরাং পদ্ধতিটি কেবল সাসের ক্ষেত্রেই কার্যকর নয়।


0

একেবারেই না. এই থ্রেডটিতে ইতিমধ্যে দুর্দান্ত উদাহরণ থাকা সত্ত্বেও, আমি আমার নিজের একটি উপাখ্যানটি ভাগ করতে চাই। 2001-এ আমি একটি রিলিজ সহ একটি সফ্টওয়্যার প্রকল্প উত্তরাধিকারসূত্রে পেয়েছি যা একটি সিডি তৈরির সাথে জড়িত। রিলিজ প্রক্রিয়াটির ডকুমেন্টেশনে আগের ইঞ্জিনিয়ার দ্বারা নথিভুক্ত 40 (!) পদক্ষেপ অন্তর্ভুক্ত ছিল, যাতে "এই কনফিগারেশন ফাইলটি খুলুন এবং 41 নম্বর লাইনে .jar ফাইলটির নাম পরিবর্তন করার মতো সংস্করণের কিছু হাস্যকর নির্দেশ ছিল of নতুন প্রকাশ "।

আমরা আক্রমণাত্মকভাবে সেই বিল্ড প্রক্রিয়াটির প্রতিটি পদক্ষেপ স্বয়ংক্রিয়ভাবে তৈরি করেছি, যেমন প্যাচ জাতীয় স্ক্র্যাপযুক্ত জিনিসগুলির সাথে হাতের লিখিত নির্দেশাবলীর বদলে। এমনকি তাদের তৃতীয় পক্ষের ইনস্টল-সরঞ্জাম বিক্রেতার সাথে তাদের প্রকল্পের ফাইলগুলি প্যাচিয়েবল করতে আমাদের টিকিট খুলতে হয়েছিল।

এই প্রক্রিয়াটি স্বয়ংক্রিয় হয়ে যাওয়ার পরে, আমরা একটি 'সিডি জুকবক্স' কিনেছিলাম। প্রতি রাতে পরীক্ষাগুলি পাস হওয়ার পরে, বিল্ড মেশিনটি স্বয়ংক্রিয়ভাবে একটি নতুন ইনস্টল সিডি তৈরি করবে। আমাদের পরীক্ষকরা পরের দিন সকালে এসে ডিস্ক ধরতে এবং সবকিছু ইনস্টলযোগ্য কিনা তা নিশ্চিত করতে পারে।

যখন আমরা একটি পরিষেবাদি হিসাবে সফ্টওয়্যার স্থাপন করতে পারি তখন আমাদের কাছে অবশ্যই শক্ত প্রতিক্রিয়া লুপ থাকে তবে অটোমেশন, প্রতিক্রিয়া, চক্রের সময়, ছোট প্রকাশনা ইত্যাদির মূল প্রিন্সিপালগুলি প্রযোজ্য।


এটি অটোমেশন সম্পর্কিত, তবে কোনওভাবেই কোনও ডিভোস সংস্থার সাথে সম্পর্কিত নয়, আমি কোথাও প্লুরি শৃঙ্খলা দল সম্পর্কে কোনও রেফারেন্স দেখতে পাচ্ছি না, কেবল তারা উত্তরাধিকার সূত্রে প্রাপ্ত স্বয়ংক্রিয় জিনিসগুলি বেছে নিয়েছে
তেনসাইবাাই

এটি 2001 ছিল ... ডিওওপ্স জিনিস হওয়ার অনেক আগে। এটি কেবল অটোমেশনই ছিল না, আমি বিশ্বাস করি এটি প্রকল্পের পরিচালনাটিকে ঠিক ঠিক একই পদ্ধতিতে প্রবাহিত করেছিল যা শেষ পর্যন্ত ডেভঅপসের 'সংস্কৃতি' হিসাবে চিহ্নিত হয়েছিল। যেমনটি, এটি কোনও সাআস সংস্থার বাইরে ডিভোপস মনোভাবের উদাহরণ।
ডেভিড বক

ডিভোপস অটোমেশন বা প্রকল্প পরিচালনার বিষয়ে নয়। এটি মূলে সিলো ভিত্তিক সংগঠন ভাঙার বিষয়ে। আমি দুঃখিত যে আমি উত্তরটি সত্যই প্রশ্নের সাথে জড়িত অনুভব করি না (এর অর্থ এটির উদ্বেগজনক নয়, তবে সঠিক জায়গায় আইএমও নয়, এবং বাস্তবে এটি কোথায় থাকতে পারে তা আমি দেখতে পাচ্ছি না, আসতে পারে পরে)
তেনসিবাই

আমি আরও একবার স্পষ্ট করার চেষ্টা করব - সিডিটি এতটা ধারাবাহিকভাবে এবং দ্রুত কাটলে, আমরা কিউএর কাছ থেকে আমাদের প্রতিক্রিয়ার চেয়ে অনেক দ্রুত প্রতিক্রিয়া পেতে পারি। এটি একটি সাইলো হ্রাস করেছে। এটি একে অপসারণ করতে পারেনি, কারণ ক্রিয়াকলাপের জন্য কেন্দ্রীয় বাজেটের আশেপাশের ফিফডমগুলি অক্ষম করার আগে আরও দু'বছর লেগেছিল, তবে এটি অবশ্যই মাকিগের একটি গুরুত্বপূর্ণ পদক্ষেপ ছিল। মুক্তির প্রক্রিয়াটি ভেঙে যাওয়ার পরে আমরা আরও অনেক তাড়াতাড়ি জানতাম। আমি এই জাতীয় অনেকগুলি জিনিস ডিভোপসকে আমার ব্যক্তিগত পথ হিসাবে ক্রেডিট করি।
ডেভিড বক

এই শেষ মন্তব্যটি এই প্রশ্নের অধীনে এই উত্তরটির আরও বোধগম্যতা এনেছে, আপনি এটি অন্তর্ভুক্ত করার জন্য আপনার সম্পাদনা করা উচিত , আমি এখনও মনে করি এটি এই ফর্ম্যাটের সাথে খাপ খায় না, তবে এই বেসরকারী বিটাতে সামগ্রিক বিবর্তনটি পর্যবেক্ষণ করলে আমার অবস্থানটি ভুল বলে মনে হয়, তাই ... এটা তোমার উপর. আমি তথ্যের জন্য কোনও সম্পাদনা ছাড়াই আমার ডাউনটোটটি সরাতে পারছি না
তেনসাইবাই
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.