আজ, বেশিরভাগ সফ্টওয়্যার পণ্য দলে বিকশিত হয়। সফল দলের বিকাশের শর্তগুলি একটি সাধারণ চিত্রের আকারে উপস্থাপন করা যেতে পারে।

একবার আপনি আপনার কোড লিখলে, আপনাকে এটি নিশ্চিত করতে হবে:

1. ।
2. আপনার সহকর্মীরা যে কোডটি লিখেছেন তা সহ এটি কিছুই ভাঙে না।

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

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

• প্রিয় মানুষ. যেকোনো প্রোগ্রামারের এক ঘণ্টা কাজ যেকোনো সার্ভারের এক ঘণ্টা কাজের চেয়ে বেশি ব্যয়বহুল।
• মানুষ ভুল করে. অতএব, পরিস্থিতি দেখা দিতে পারে যখন পরীক্ষাগুলি ভুল শাখায় চালানো হয়েছিল বা পরীক্ষকদের জন্য ভুল প্রতিশ্রুতি সংকলিত হয়েছিল।
• মানুষ অলস. সময়ে সময়ে, যখন আমি একটি কাজ শেষ করি, তখন চিন্তা জাগে: “চেক করার কী আছে? আমি দুটি লাইন লিখেছিলাম - সবকিছু কাজ করে! আমি মনে করি আপনাদের মধ্যে কারো কারো মাঝে মাঝে এমন চিন্তাভাবনা আসে। কিন্তু আপনি সবসময় চেক করা উচিত.

অ্যাভিটো মোবাইল ডেভেলপমেন্ট টিমে কীভাবে অবিচ্ছিন্ন ইন্টিগ্রেশন বাস্তবায়িত এবং বিকাশ করা হয়েছিল, কীভাবে তারা প্রতিদিন 0 থেকে 450 বিল্ডের মধ্যে গিয়েছিল এবং যে বিল্ড মেশিনগুলি দিনে 200 ঘন্টা একত্রিত হয়, নিকোলাই নেস্টেরভ বলেছেন (নেস্টেরভ) CI/CD অ্যান্ড্রয়েড অ্যাপ্লিকেশনের সমস্ত বিবর্তনীয় পরিবর্তনে অংশগ্রহণকারী।

গল্পটি একটি অ্যান্ড্রয়েড কমান্ডের উদাহরণের উপর ভিত্তি করে তৈরি করা হয়েছে, তবে বেশিরভাগ পন্থা iOS এও প্রযোজ্য।

এক সময়, একজন ব্যক্তি অ্যাভিটো অ্যান্ড্রয়েড দলে কাজ করেছিলেন। সংজ্ঞা অনুসারে, ক্রমাগত একীকরণ থেকে তার কিছুর প্রয়োজন ছিল না: সংহত করার মতো কেউ ছিল না।

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

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

চেক

আপনার চোখ দিয়ে কোড দেখা শীতল, কিন্তু যথেষ্ট নয়। তাই স্বয়ংক্রিয় চেক চালু করা হচ্ছে।

• প্রথমত, আমরা চেক করি ARK সমাবেশ.
• অনেক জুনিট পরীক্ষা.
• আমরা কোড কভারেজ বিবেচনা করিযেহেতু আমরা পরীক্ষা চালাচ্ছি।

এই চেকগুলি কীভাবে চালানো উচিত তা বোঝার জন্য, আসুন অ্যাভিটোতে উন্নয়ন প্রক্রিয়াটি দেখি।

এটি এই মত পরিকল্পিতভাবে উপস্থাপন করা যেতে পারে:

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

কেউ তাদের ল্যাপটপে স্ক্যান চালানো পছন্দ করে না। যখন একজন বিকাশকারী একটি বৈশিষ্ট্য শেষ করে, তখন তিনি দ্রুত এটিকে ধাক্কা দিতে এবং একটি টান অনুরোধ খুলতে চান। যদি এই মুহুর্তে কিছু দীর্ঘ চেক চালু করা হয়, তবে এটি কেবল খুব আনন্দদায়ক নয়, তবে বিকাশকে ধীর করে দেয়: ল্যাপটপটি কিছু পরীক্ষা করার সময়, এটিতে সাধারণভাবে কাজ করা অসম্ভব।

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

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

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

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

বেসিক সিআই সম্পূর্ণরূপে সেট আপ করতে আমাদের দুই দিন লেগেছে (এরপরে সময়ের অনুমান আনুমানিক, স্কেলের জন্য প্রয়োজন)।

এর পরে, আমরা আরও ভাবতে শুরু করি - আমরা কি সঠিকভাবে পরীক্ষা করছি? আমরা কি সঠিকভাবে পুল অনুরোধের উপর বিল্ড চালাচ্ছি?

যে শাখা থেকে পুল অনুরোধ খোলা হয়েছিল তার শেষ কমিটের ভিত্তিতে আমরা বিল্ড শুরু করেছি। কিন্তু এই কমিটের পরীক্ষা শুধুমাত্র দেখাতে পারে যে ডেভেলপার যে কোডটি লিখেছেন সেটি কাজ করে। কিন্তু তারা প্রমাণ করে না যে তিনি কিছু ভাঙেননি। আসলে, একটি বৈশিষ্ট্য একত্রিত হওয়ার পরে আপনাকে বিকাশ শাখার অবস্থা পরীক্ষা করতে হবে।

এটি করার জন্য, আমরা একটি সাধারণ ব্যাশ স্ক্রিপ্ট লিখেছি premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

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

সমস্যাটি স্থানীয়করণ করতে, একটি সমাধান খুঁজে পেতে এবং এই স্ক্রিপ্টটি লিখতে তিন দিন সময় লেগেছিল৷

অ্যাপ্লিকেশনটি বিকশিত হয়েছে, আরও বেশি কাজ দেখা দিয়েছে, দল বেড়েছে এবং premerge.sh মাঝে মাঝে আমাদের হতাশ করতে শুরু করেছে। বিকাশে বিরোধপূর্ণ পরিবর্তন হয়েছে যা বিল্ডকে ভেঙে দিয়েছে।

এটি কীভাবে ঘটে তার একটি উদাহরণ:

দুইজন বিকাশকারী একই সাথে A এবং B বৈশিষ্ট্যের উপর কাজ শুরু করে৷ বৈশিষ্ট্য A-এর বিকাশকারী প্রকল্পে একটি অব্যবহৃত বৈশিষ্ট্য আবিষ্কার করে answer() এবং, একজন ভালো ছেলে স্কাউটের মতো, এটিকে সরিয়ে দেয়। একই সময়ে, বৈশিষ্ট্য B এর বিকাশকারী তার শাখায় এই ফাংশনে একটি নতুন কল যোগ করে।

বিকাশকারীরা তাদের কাজ শেষ করে এবং একই সময়ে একটি টান অনুরোধ খোলে। বিল্ডগুলি চালু করা হয়েছে, premerge.sh সর্বশেষ বিকাশের অবস্থা সম্পর্কিত উভয় পুল অনুরোধ পরীক্ষা করে - সমস্ত চেক সবুজ। এর পরে, বৈশিষ্ট্য A এর পুল অনুরোধ একত্রিত হয়, বৈশিষ্ট্য B এর পুল অনুরোধ একত্রিত হয়... বুম! বিকাশ বিরতি কারণ বিকাশ কোড একটি অস্তিত্বহীন ফাংশন একটি কল ধারণ করে.

যখন এটি বিকাশ করতে যাচ্ছে না, এটি স্থানীয় দুর্যোগ. পুরো দল কিছু সংগ্রহ করে পরীক্ষার জন্য জমা দিতে পারে না।

এটি তাই ঘটেছে যে আমি প্রায়শই অবকাঠামোগত কাজগুলিতে কাজ করেছি: বিশ্লেষণ, নেটওয়ার্ক, ডাটাবেস। অর্থাৎ, আমিই সেই ফাংশন এবং ক্লাসগুলি লিখেছিলাম যা অন্যান্য বিকাশকারীরা ব্যবহার করে। এই কারণে, আমি প্রায়ই একই পরিস্থিতিতে নিজেকে খুঁজে পেয়েছি। এই ছবিটাও কিছুক্ষণ ঝুলিয়ে রেখেছিলাম।

যেহেতু এটি আমাদের জন্য উপযুক্ত নয়, তাই আমরা কীভাবে এটি প্রতিরোধ করা যায় তার বিকল্পগুলি অন্বেষণ করতে শুরু করি৷

কীভাবে বিকাশ ভাঙতে হবে না

প্রথম বিকল্প: বিকাশ আপডেট করার সময় সমস্ত পুল অনুরোধ পুনর্নির্মাণ করুন। যদি, আমাদের উদাহরণে, বৈশিষ্ট্য A সহ পুল অনুরোধটি বিকাশে প্রথম অন্তর্ভুক্ত হয়, তবে বৈশিষ্ট্য B-এর পুল অনুরোধটি পুনর্নির্মাণ করা হবে, এবং সেই অনুযায়ী, একটি সংকলন ত্রুটির কারণে চেকগুলি ব্যর্থ হবে৷

এটি কতক্ষণ লাগবে তা বোঝার জন্য, দুটি PR সহ একটি উদাহরণ বিবেচনা করুন৷ আমরা দুটি পিআর খুলি: দুটি বিল্ড, দুটি চেকের রান। প্রথম পিআরটি বিকাশে একত্রিত হওয়ার পরে, দ্বিতীয়টি পুনর্নির্মাণ করা দরকার। মোট, দুটি PR-এর জন্য তিনটি চেকের প্রয়োজন: 2 + 1 = 3৷

নীতিগতভাবে, এটা ঠিক আছে. কিন্তু আমরা পরিসংখ্যান দেখেছি, এবং আমাদের দলের সাধারণ পরিস্থিতি ছিল 10টি খোলা পিআর, এবং তারপরে চেকের সংখ্যা হল অগ্রগতির যোগফল: 10 + 9 +... + 1 = 55। অর্থাৎ, 10 গ্রহণ করা PRs, আপনাকে 55 বার পুনর্নির্মাণ করতে হবে। এবং এটি একটি আদর্শ পরিস্থিতিতে, যখন সমস্ত চেক প্রথমবার পাস হয়, যখন এই ডজন প্রক্রিয়াকরণের সময় কেউ অতিরিক্ত পুল অনুরোধ খোলে না।

নিজেকে একজন ডেভেলপার হিসাবে কল্পনা করুন যিনি "একত্রীকরণ" বোতামে ক্লিক করার জন্য প্রথম হতে হবে, কারণ যদি একজন প্রতিবেশী এটি করে, তাহলে আপনাকে অপেক্ষা করতে হবে যতক্ষণ না সমস্ত বিল্ডগুলি আবার হয়ে যায়... না, এটি কাজ করবে না। , এটা গুরুতরভাবে উন্নয়ন ধীর হবে.

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

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

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

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

এই প্লাগইনটি বাস্তবায়ন করার আগে, আমরা প্রতি পুল অনুরোধের গড় 2,7 রিভিউ রান করেছি। প্লাগইন সহ 3,6 লঞ্চ ছিল। এই আমাদের উপযুক্ত.

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

বিটবাকেট প্লাগইনের প্রথম সংস্করণ লিখতে আমাদের দুই সপ্তাহ সময় লেগেছে।

নতুন চেক

এদিকে আমাদের দল বাড়তে থাকে। নতুন চেক যোগ করা হয়েছে.

আমরা ভেবেছিলাম: যদি তাদের প্রতিরোধ করা যায় তবে কেন ভুল করবেন? আর এজন্যই তারা বাস্তবায়ন করেছে স্ট্যাটিক কোড বিশ্লেষণ. আমরা লিন্ট দিয়ে শুরু করেছি, যা অ্যান্ড্রয়েড SDK-তে অন্তর্ভুক্ত। কিন্তু সেই সময়ে তিনি কোটলিন কোডের সাথে কীভাবে কাজ করবেন তা জানতেন না এবং আমাদের কাছে ইতিমধ্যেই কোটলিনে 75% অ্যাপ্লিকেশন লেখা ছিল। অতএব, অন্তর্নির্মিত বেশী লিন্ট যোগ করা হয়েছে অ্যান্ড্রয়েড স্টুডিও পরীক্ষা করে।

এটি করার জন্য, আমাদের অনেক বিকৃত করতে হয়েছিল: অ্যান্ড্রয়েড স্টুডিও নিন, এটি ডকারে প্যাকেজ করুন এবং এটি একটি ভার্চুয়াল মনিটর দিয়ে সিআই-তে চালান, যাতে এটি মনে করে এটি একটি আসল ল্যাপটপে চলছে। কিন্তু এটা কাজ.

এই সময়ে আমরা প্রচুর লেখালেখি শুরু করি ইন্সট্রুমেন্টেশন পরীক্ষা এবং বাস্তবায়িত স্ক্রিনশট পরীক্ষা. এটি যখন একটি পৃথক ছোট দৃশ্যের জন্য একটি রেফারেন্স স্ক্রিনশট তৈরি করা হয়, এবং পরীক্ষাটি ভিউ থেকে একটি স্ক্রিনশট নেওয়া এবং এটিকে পিক্সেল দ্বারা সরাসরি পিক্সেলের সাথে তুলনা করে। যদি কোনও অমিল থাকে, তাহলে এর মানে হল লেআউটটি কোথাও ভুল হয়েছে বা শৈলীতে কিছু ভুল হয়েছে।

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

ফায়ারবেস টেস্ট ল্যাব

এটি বেছে নেওয়া হয়েছে কারণ ফায়ারবেস একটি Google পণ্য, যার অর্থ এটি নির্ভরযোগ্য এবং কখনও মারা যাওয়ার সম্ভাবনা নেই৷ দামগুলি যুক্তিসঙ্গত: একটি বাস্তব ডিভাইসের অপারেশন প্রতি ঘন্টায় $5, একটি এমুলেটরের অপারেশন প্রতি ঘন্টায় 1$।

আমাদের CI-এ ফায়ারবেস টেস্ট ল্যাব প্রয়োগ করতে প্রায় তিন সপ্তাহ সময় লেগেছে।

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

ডকার + পাইথন + ব্যাশ

আমরা ডকার নিয়েছি, এতে স্টাফ এমুলেটর রয়েছে, পাইথনে একটি সাধারণ প্রোগ্রাম লিখেছে, যা সঠিক মুহুর্তে প্রয়োজনীয় সংস্করণে প্রয়োজনীয় সংখ্যক এমুলেটর নিয়ে আসে এবং প্রয়োজনে সেগুলি বন্ধ করে দেয়। এবং, অবশ্যই, কয়েকটি ব্যাশ স্ক্রিপ্ট - সেগুলি ছাড়া আমরা কোথায় থাকব?

আমাদের নিজস্ব পরীক্ষার পরিবেশ তৈরি করতে পাঁচ সপ্তাহ লেগেছে।

ফলস্বরূপ, প্রতিটি পুল অনুরোধের জন্য চেকের একটি বিস্তৃত মার্জ-ব্লকিং তালিকা ছিল:

• ARK সমাবেশ;
• জুনিট পরীক্ষা;
• লিন্ট;
• অ্যান্ড্রয়েড স্টুডিও চেক;
• ইন্সট্রুমেন্টেশন পরীক্ষা;
• স্ক্রিনশট পরীক্ষা।

এটি অনেক সম্ভাব্য ভাঙ্গন প্রতিরোধ করেছে। প্রযুক্তিগতভাবে সবকিছু কাজ করেছে, তবে বিকাশকারীরা অভিযোগ করেছেন যে ফলাফলের জন্য অপেক্ষা করা খুব দীর্ঘ ছিল।

কতক্ষণ অত্যন্ত দীর্ঘ? আমরা বিশ্লেষণ সিস্টেমে Bitbucket এবং TeamCity থেকে ডেটা আপলোড করেছি এবং বুঝতে পেরেছি গড় অপেক্ষার সময় 45 মিনিট. অর্থাৎ, একজন বিকাশকারী, একটি পুল অনুরোধ খোলার সময়, বিল্ড ফলাফলের জন্য গড়ে 45 মিনিট অপেক্ষা করে। আমার মতে, এটি অনেক, এবং আপনি এর মতো কাজ করতে পারবেন না।

অবশ্যই, আমরা আমাদের সমস্ত বিল্ডের গতি বাড়ানোর সিদ্ধান্ত নিয়েছি।

এর গতি বাড়ানো যাক

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

খুব বেশি সময় নেয় এমন চেকগুলি সরানো হচ্ছে৷

আমাদের ক্রমাগত ইন্টিগ্রেশন এই ধরনের ত্রুটি এবং সমস্যা ধরতে পারে।

• যাচ্ছি না. বিরোধপূর্ণ পরিবর্তনের কারণে কিছু তৈরি না হলে CI একটি সংকলন ত্রুটি ধরতে পারে। আমি আগেই বলেছি, তখন কেউ কিছু করতে পারে না, উন্নয়ন বন্ধ হয়ে যায় এবং সবাই ঘাবড়ে যায়।
• আচরণে বাগ. উদাহরণস্বরূপ, যখন অ্যাপ্লিকেশনটি তৈরি করা হয়, কিন্তু আপনি একটি বোতাম টিপলে ক্র্যাশ হয়, বা বোতামটি মোটেও চাপা হয় না। এটি খারাপ কারণ এই ধরনের বাগ ব্যবহারকারীর কাছে পৌঁছাতে পারে।
• লেআউটে বাগ. উদাহরণস্বরূপ, একটি বোতাম ক্লিক করা হয়েছে, কিন্তু বাম দিকে 10 পিক্সেল সরানো হয়েছে।
• প্রযুক্তিগত ঋণ বৃদ্ধি.

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

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

ফলস্বরূপ, আমাদের বাকি ছিল:

• ARK সমাবেশ;
• জুনিট পরীক্ষা;
• ইন্সট্রুমেন্টেশন পরীক্ষা।

গ্রেডল রিমোট ক্যাশে

ভারী চেক ছাড়া, সবকিছু ভাল হয়ে ওঠে. কিন্তু পরিপূর্ণতার কোন সীমা নেই!

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

গ্র্যাডল রিমোট ক্যাশে এমন একটি পরিষেবা যা পৃথক মডিউলে পৃথক কাজের জন্য আর্টিফ্যাক্ট তৈরি করতে পারে। গ্রেডল, আসলে কোড কম্পাইল করার পরিবর্তে, রিমোট ক্যাশে নক করতে HTTP ব্যবহার করে এবং জিজ্ঞাসা করে যে কেউ ইতিমধ্যে এই কাজটি সম্পাদন করেছে কিনা। যদি হ্যাঁ, এটি কেবল ফলাফল ডাউনলোড করে।

Gradle রিমোট ক্যাশে চালানো সহজ কারণ Gradle একটি ডকার ইমেজ প্রদান করে। আমরা তিন ঘন্টার মধ্যে এটি করতে পেরেছি।

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

নীচে ক্যাশে মিস গ্রাফ রয়েছে।

একেবারে শুরুতে, ক্যাশে মিস হওয়ার শতাংশ ছিল প্রায় 65। তিন সপ্তাহ পর, আমরা এই মানটিকে 20%-এ উন্নীত করতে পেরেছি। দেখা গেল যে অ্যান্ড্রয়েড অ্যাপ্লিকেশনটি যে কাজগুলি সংগ্রহ করে তাতে অদ্ভুত ট্রানজিটিভ নির্ভরতা রয়েছে, যার কারণে গ্রেডল ক্যাশে মিস করেছে।

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

প্রভাব বিশ্লেষণ

একটি টানার অনুরোধে, আমরা গিট ডিফ সংগ্রহ করি এবং পরিবর্তিত গ্রেডল মডিউলগুলি খুঁজে পাই।

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

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

ইন্সট্রুমেন্টেশন পরীক্ষার অপারেশন আপগ্রেড করা যাতে তারা শুধুমাত্র জড়িত মডিউলগুলি পরীক্ষা করতে প্রায় আট সপ্তাহ সময় নেয়।

পরিদর্শন ত্বরান্বিত করার ব্যবস্থা সফলভাবে কাজ করেছে। 45 মিনিট থেকে আমরা প্রায় 15-এ গিয়েছিলাম। নির্মাণের জন্য এক ঘন্টার এক চতুর্থাংশ অপেক্ষা করা ইতিমধ্যেই স্বাভাবিক।

কিন্তু এখন ডেভেলপাররা অভিযোগ করতে শুরু করেছেন যে তারা বুঝতে পারছেন না কোন বিল্ডগুলি চালু করা হচ্ছে, লগ কোথায় দেখতে হবে, কেন বিল্ডটি লাল, কোন পরীক্ষায় ব্যর্থ হয়েছে ইত্যাদি।

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

বিশদ প্রতিক্রিয়ার জন্য ছয় সপ্তাহ ব্যয় করা হয়েছিল।

পরিকল্পনা

চলুন সাম্প্রতিক ইতিহাসে যাওয়া যাক। প্রতিক্রিয়া সমস্যা সমাধান করার পরে, আমরা একটি নতুন স্তরে পৌঁছেছি - আমরা আমাদের নিজস্ব এমুলেটর খামার তৈরি করার সিদ্ধান্ত নিয়েছি। যখন অনেক পরীক্ষা এবং এমুলেটর থাকে, তখন তাদের পরিচালনা করা কঠিন। ফলস্বরূপ, আমাদের সমস্ত এমুলেটর নমনীয় সম্পদ ব্যবস্থাপনা সহ k8s ক্লাস্টারে চলে গেছে।

এছাড়াও, অন্যান্য পরিকল্পনা আছে।

• রিটার্ন লিন্ট (এবং অন্যান্য স্ট্যাটিক বিশ্লেষণ)। আমরা ইতিমধ্যে এই দিকে কাজ করছি।
• পিআর ব্লকারে সবকিছু চালান শেষ থেকে শেষ পরীক্ষা সমস্ত SDK সংস্করণে।

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

টিপস

আমি যদি শুধু এক টুকরো পরামর্শ দিতে পারি তা হবে:

শেল স্ক্রিপ্ট সঙ্গে সতর্কতা অবলম্বন করুন!

Bash একটি খুব নমনীয় এবং শক্তিশালী টুল, এটি স্ক্রিপ্ট লিখতে খুব সুবিধাজনক এবং দ্রুত। তবে আপনি এটির সাথে একটি ফাঁদে পড়তে পারেন এবং দুর্ভাগ্যবশত, আমরা এতে পড়েছি।

এটি সমস্ত সহজ স্ক্রিপ্ট দিয়ে শুরু হয়েছিল যা আমাদের বিল্ড মেশিনে চলে:

#!/usr/bin/env bash
./gradlew assembleDebug

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

আপনি এই ধরনের স্ক্রিপ্টগুলির বিকাশের জন্য শ্রম খরচ কল্পনা করতে পারেন। আমি আপনাকে এই ফাঁদে না পড়ার পরামর্শ দিচ্ছি।

কি প্রতিস্থাপন করা যেতে পারে?

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

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

টিপ #2: কোডে অবকাঠামো সংরক্ষণ করুন।

এটি সুবিধাজনক যখন ক্রমাগত ইন্টিগ্রেশন সেটিং Jenkins বা TeamCity, ইত্যাদির UI ইন্টারফেসে সংরক্ষণ করা হয় না, কিন্তু সরাসরি প্রজেক্ট রিপোজিটরিতে টেক্সট ফাইল আকারে সংরক্ষণ করা হয়। এটি সংস্করণযোগ্যতা দেয়। অন্য শাখায় কোডটি রোলব্যাক করা বা তৈরি করা কঠিন হবে না।

স্ক্রিপ্ট একটি প্রকল্পে সংরক্ষণ করা যেতে পারে. পরিবেশ নিয়ে কী করবেন?

টিপ #3: ডকার পরিবেশের সাথে সাহায্য করতে পারে।

এটি অবশ্যই অ্যান্ড্রয়েড ডেভেলপারদের সাহায্য করবে; দুর্ভাগ্যবশত iOS এর এখনও একটি নেই।

এটি একটি সাধারণ ডকার ফাইলের একটি উদাহরণ যা jdk এবং android-sdk ধারণ করে:

FROM openjdk:8

ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip" 
    ANDROID_HOME="/usr/local/android-sdk" 
    ANDROID_VERSION=26 
    ANDROID_BUILD_TOOLS_VERSION=26.0.2

# Download Android SDK
RUN mkdir "$ANDROID_HOME" .android 
    && cd "$ANDROID_HOME" 
    && curl -o sdk.zip $SDK_URL 
    && unzip sdk.zip 
    && rm sdk.zip 
    && yes | $ANDROID_HOME/tools/bin/sdkmanager --licenses

# Install Android Build Tool and Libraries
RUN $ANDROID_HOME/tools/bin/sdkmanager --update
RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" 
    "platforms;android-${ANDROID_VERSION}" 
    "platform-tools"

RUN mkdir /application
WORKDIR /application

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

দুটি প্রধান কারণ কেন এটি বোঝায় তা হল মাপযোগ্যতা এবং পুনরাবৃত্তিযোগ্যতা। ডকার ব্যবহার করে, আপনি দ্রুত এক ডজন বিল্ড এজেন্ট বাড়াতে পারেন যেগুলির আগেরটির মতো একই পরিবেশ থাকবে। এটি সিআই ইঞ্জিনিয়ারদের জীবনকে অনেক সহজ করে তোলে। অ্যান্ড্রয়েড-এসডিকে ডকারে ঠেলে দেওয়া বেশ সহজ, কিন্তু এমুলেটরগুলির সাথে এটি একটু বেশি কঠিন: আপনাকে একটু কঠোর পরিশ্রম করতে হবে (অথবা গিটহাব থেকে আবার ডাউনলোড করুন)।

টিপ নং 4: ভুলে যাবেন না যে পরিদর্শনগুলি পরিদর্শনের জন্য নয়, মানুষের জন্য করা হয়৷

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

টিপ #5: ক্রমাগত ইন্টিগ্রেশন বিকাশ করার সময় বাস্তববাদী হন।

আপনি কোন ধরনের ত্রুটি প্রতিরোধ করতে চান, কত সম্পদ, সময় এবং কম্পিউটার সময় ব্যয় করতে ইচ্ছুক তা স্পষ্টভাবে বুঝুন। যে চেকগুলি খুব বেশি সময় নেয়, উদাহরণস্বরূপ, রাতারাতি স্থগিত করা যেতে পারে৷ এবং তাদের মধ্যে যারা খুব গুরুত্বপূর্ণ ত্রুটি ধরতে পারে না তাদের সম্পূর্ণরূপে পরিত্যাগ করা উচিত।

টিপ #6: রেডিমেড টুল ব্যবহার করুন।

এখন অনেক কোম্পানি আছে যারা ক্লাউড সিআই প্রদান করে।

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

টিপ #7: একটি বড় দলে, ইন-হাউস সমাধানগুলি আরও লাভজনক।

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

অর্থনীতি আমাদের সমগ্র জীবন বর্ণনা করে, যার মধ্যে ক্রমাগত একীকরণও রয়েছে। আমি আমাদের ক্রমাগত একীকরণের বিকাশের প্রতিটি পর্যায়ে শ্রম ব্যয়ের একটি সময়সূচী তৈরি করেছি।

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

আমরা এই ধারণা দিয়ে শুরু করেছি যে অটোমেশন প্রয়োজন কারণ মানুষ ব্যয়বহুল, তারা ভুল করে এবং অলস। কিন্তু মানুষও স্বয়ংক্রিয়। অতএব, সমস্ত একই সমস্যা অটোমেশন প্রযোজ্য.

• অটোমেশন ব্যয়বহুল। শ্রম সময়সূচী মনে রাখবেন।
• যখন এটি অটোমেশন আসে, মানুষ ভুল করে।
• কখনও কখনও এটি স্বয়ংক্রিয় করতে খুব অলস, কারণ সবকিছু সেভাবে কাজ করে। অন্য কিছুর উন্নতি কেন, কেন এই সব কন্টিনিউয়াস ইন্টিগ্রেশন?

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

ক্রমাগত একীকরণ অনুশীলন করুন। তবে পরিমিতভাবে।

যাইহোক, নিকোলাই নেস্টেরভ কেবল নিজেই দুর্দান্ত প্রতিবেদন দেয় না, তবে প্রোগ্রাম কমিটির সদস্যও AppsConf এবং অন্যদের আপনার জন্য অর্থপূর্ণ বক্তৃতা প্রস্তুত করতে সাহায্য করে। পরবর্তী কনফারেন্স প্রোগ্রামের সম্পূর্ণতা এবং উপযোগিতা বিষয়গুলির দ্বারা মূল্যায়ন করা যেতে পারে সময়সূচী. এবং বিস্তারিত জানতে, 22-23 এপ্রিল ইনফোস্পেসে আসুন।

উত্স: www.habr.com