ক্রমাগত ইন্টিগ্রেশন, গিটহাব অ্যাকশন এবং সোনার ক্লাউড সম্পর্কে আপনার যা জানা দরকার

মোজিলা প্রজেক্ট চালু হওয়ার সময় আমি প্রথম কন্টিনিউয়াস ইন্টিগ্রেশন (সিআই) ধারণার মধ্যে পড়েছিলাম। এটি প্রক্রিয়ার অংশ হিসাবে একটি প্রাথমিক বিল্ড সার্ভার অন্তর্ভুক্ত করেছিল এবং এটি সেই সময়ে বিপ্লবী ছিল। আমি একটি C++ প্রকল্প পরিচালনা করছিলাম যা তৈরি করতে এবং লিঙ্ক করতে 2 ঘন্টা সময় নেয়।

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

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

ক্রমাগত ইন্টিগ্রেশন হল একটি সফ্টওয়্যার ডেভেলপমেন্ট অনুশীলন যেখানে কোড পরিবর্তনগুলি স্বয়ংক্রিয়ভাবে তৈরি এবং ঘন ঘন এবং ধারাবাহিকভাবে পরীক্ষা করা হয়।

CI-এর লক্ষ্য হল যত তাড়াতাড়ি সম্ভব ইন্টিগ্রেশন সমস্যাগুলি ধরা এবং সমাধান করা, বাগ এবং অন্যান্য সমস্যাগুলির ঝুঁকি হ্রাস করে উত্পাদনে পিছলে যাওয়া৷

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

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

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

আমি ধারণাটির একটি বড় অনুরাগী, কিন্তু কিছু জিনিস আমাদের নিরীক্ষণ করতে হবে।

ক্রমাগত ইন্টিগ্রেশন টুলস

অনেক শক্তিশালী ক্রমাগত ইন্টিগ্রেশন টুল আছে. এখানে কিছু সাধারণভাবে ব্যবহৃত সরঞ্জাম রয়েছে:

• জেনকিন্স : জেনকিন্স হল সবচেয়ে জনপ্রিয় CI টুলগুলির মধ্যে একটি, যা বিভিন্ন প্রোগ্রামিং ল্যাঙ্গুয়েজকে সমর্থন করতে এবং টুল তৈরি করার জন্য বিস্তৃত প্লাগইন এবং ইন্টিগ্রেশন প্রদান করে। এটি ওপেন সোর্স এবং বিল্ড পাইপলাইন স্থাপন এবং পরিচালনার জন্য একটি ব্যবহারকারী-বান্ধব ইন্টারফেস অফার করে।

  
  

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

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

• CircleCI : CircleCI হল একটি ক্লাউড-ভিত্তিক CI টুল যা বিস্তৃত প্রোগ্রামিং ভাষা এবং বিল্ড টুল সমর্থন করে। এটি একটি ব্যবহারকারী-বান্ধব ইন্টারফেস অফার করে, তবে এর বড় বিক্রয় পয়েন্ট হল বিল্ড এবং ডেলিভারির গতি।

• গিটল্যাব সিআই/সিডি : গিটল্যাব হল একটি জনপ্রিয় সোর্স কোড ম্যানেজমেন্ট টুল যাতে অন্তর্নির্মিত সিআই/সিডি ক্ষমতা রয়েছে। গিটল্যাব সমাধান নমনীয় কিন্তু সহজ; এটি গিটল্যাব গোলকের বাইরেও কিছু শিল্পের আকর্ষণ অর্জন করেছে।

• Bitbucket Pipelines : Bitbucket Pipelines হল Atlassian-এর একটি ক্লাউড-ভিত্তিক CI টুল যা তাদের সোর্স কোড ম্যানেজমেন্ট টুল Bitbucket-এর সাথে নির্বিঘ্নে সংহত করে। যেহেতু এটি একটি আটলাসিয়ান পণ্য, এটি নির্বিঘ্ন JIRA ইন্টিগ্রেশন এবং খুব তরল, এন্টারপ্রাইজ-ভিত্তিক কার্যকারিতা প্রদান করে।

লক্ষ্য করুন আমি গিটহাব অ্যাকশন উল্লেখ করিনি যা আমরা শীঘ্রই পাব। CI সরঞ্জামগুলির তুলনা করার সময় বিবেচনা করার জন্য বেশ কয়েকটি কারণ রয়েছে:

• ব্যবহারের সহজতা: কিছু CI টুলের একটি সহজ সেটআপ প্রক্রিয়া এবং ব্যবহারকারী-বান্ধব ইন্টারফেস রয়েছে, যা বিকাশকারীদের জন্য শুরু করা এবং তাদের বিল্ড পাইপলাইনগুলি পরিচালনা করা সহজ করে তোলে।

• সোর্স কোড ম্যানেজমেন্ট (SCM) টুলের সাথে ইন্টিগ্রেশন যেমন GitHub, GitLab, এবং Bitbucket। এটি দলগুলির জন্য তাদের বিল্ড, পরীক্ষা এবং স্থাপনার প্রক্রিয়াগুলি স্বয়ংক্রিয় করা সহজ করে তোলে।

• বিভিন্ন প্রোগ্রামিং ল্যাঙ্গুয়েজ এবং বিল্ড টুলের জন্য সমর্থন: বিভিন্ন CI টুল বিভিন্ন প্রোগ্রামিং ল্যাঙ্গুয়েজ এবং বিল্ড টুল সমর্থন করে, তাই আপনার ডেভেলপমেন্ট স্ট্যাকের সাথে সামঞ্জস্যপূর্ণ একটি টুল বেছে নেওয়া গুরুত্বপূর্ণ।

• পরিমাপযোগ্যতা: কিছু CI সরঞ্জামগুলি জটিল বিল্ড পাইপলাইন সহ বৃহত্তর সংস্থাগুলির জন্য আরও উপযুক্ত, অন্যগুলি সহজ প্রয়োজনের সাথে ছোট দলগুলির জন্য আরও উপযুক্ত।

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

• বৈশিষ্ট্য: বিভিন্ন CI সরঞ্জামগুলি স্বতন্ত্র বৈশিষ্ট্যগুলি অফার করে, যেমন রিয়েল-টাইম বিল্ড এবং পরীক্ষার ফলাফল, সমান্তরাল বিল্ডগুলির জন্য সমর্থন এবং বিল্ট-ইন স্থাপনার ক্ষমতা।

সাধারণভাবে, জেনকিন্স তার বহুমুখীতা এবং বিস্তৃত প্লাগইন লাইব্রেরির জন্য পরিচিত, এটি জটিল বিল্ড পাইপলাইন সহ দলগুলির জন্য একটি জনপ্রিয় পছন্দ করে তোলে। Travis CI এবং CircleCI জনপ্রিয় SCM সরঞ্জামগুলির সাথে তাদের ব্যবহার সহজ এবং একীকরণের জন্য পরিচিত, যা তাদের ছোট থেকে মাঝারি আকারের দলগুলির জন্য একটি ভাল পছন্দ করে তোলে।

গিটল্যাব সিআই/সিডি তাদের সোর্স কোড পরিচালনার জন্য গিটল্যাব ব্যবহারকারী দলগুলির জন্য একটি জনপ্রিয় পছন্দ কারণ এটি সমন্বিত CI/CD ক্ষমতাগুলি অফার করে। Bitbucket Pipelines তাদের সোর্স কোড পরিচালনার জন্য Bitbucket ব্যবহারকারী দলগুলির জন্য একটি ভাল পছন্দ, কারণ এটি প্ল্যাটফর্মের সাথে নির্বিঘ্নে একত্রিত হয়।

ক্লাউড বনাম অন-প্রিমিস

একটি CI সমাধান নির্বাচন করার সময় এজেন্টদের হোস্টিং বিবেচনা করা একটি গুরুত্বপূর্ণ বিষয়। এজেন্ট হোস্টিংয়ের জন্য দুটি প্রধান বিকল্প রয়েছে: ক্লাউড-ভিত্তিক এবং অন-প্রিমিস।

• ক্লাউড-ভিত্তিক : ক্লাউড-ভিত্তিক CI সমাধান, যেমন Travis CI, CircleCI, GitHub Actions, এবং Bitbucket Pipelines, ক্লাউডে তাদের নিজস্ব সার্ভারে এজেন্টদের হোস্ট করে। এর মানে হল যে আপনাকে অন্তর্নিহিত অবকাঠামো পরিচালনার বিষয়ে চিন্তা করতে হবে না এবং আপনি ক্লাউডের মাপযোগ্যতা এবং নির্ভরযোগ্যতার সুবিধা নিতে পারেন।

• অন-প্রিমিস : জেনকিন্সের মতো অন-প্রিমিস সিআই সমাধান আপনাকে আপনার নিজের সার্ভারে এজেন্টদের হোস্ট করার অনুমতি দেয়। এটি আপনাকে অন্তর্নিহিত অবকাঠামোর উপর আরও নিয়ন্ত্রণ দেয় তবে সার্ভারগুলি পরিচালনা এবং রক্ষণাবেক্ষণের জন্য আরও প্রচেষ্টার প্রয়োজন।

একটি CI সমাধান নির্বাচন করার সময়, আপনার দলের নির্দিষ্ট চাহিদা এবং প্রয়োজনীয়তা বিবেচনা করা গুরুত্বপূর্ণ।

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

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

এজেন্ট স্টেটফুলনেস

স্টেটফুলনেস নির্ধারণ করে যে এজেন্টরা তাদের ডেটা এবং বিল্ডগুলির মধ্যে কনফিগারেশন ধরে রাখে কিনা।

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

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

সেরা পদ্ধতির বিষয়ে CI সমর্থকদের মধ্যে একটি প্রাণবন্ত বিতর্ক রয়েছে। রাষ্ট্রহীন এজেন্টরা একটি পরিষ্কার এবং সহজে পুনরুৎপাদনের পরিবেশ প্রদান করে। আমি বেশিরভাগ ক্ষেত্রেই সেগুলি বেছে নিই এবং মনে করি সেগুলিই ভাল পন্থা৷

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

একটি স্টেটলেস এজেন্টের সাথে, যখন একটি CI প্রক্রিয়া ব্যর্থ হয়, তখন আপনার কাছে সাধারণত লগ ছাড়া অন্য কোনো তদন্তের উপায় থাকে না।

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

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

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

পুনরাবৃত্তিযোগ্য বিল্ড

পুনরাবৃত্তিযোগ্য বিল্ডগুলি পরিবেশ বা বিল্ডটি সঞ্চালিত হওয়ার সময় নির্বিশেষে প্রতিবার একটি বিল্ড সঞ্চালিত হওয়ার সময় একই সঠিক সফ্টওয়্যার আর্টিফ্যাক্ট তৈরি করার ক্ষমতাকে বোঝায়।

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

বিরতিহীন ব্যর্থতাগুলি সর্বত্র DevOps-এর ক্ষতিকর, এবং সেগুলি ট্র্যাক করা বেদনাদায়ক।

দুর্ভাগ্যক্রমে, কোন সহজ সমাধান নেই। যতটা আমরা এটি চাই, কিছু অস্বস্তি যুক্তিসঙ্গত জটিলতার সাথে প্রকল্পগুলিতে তার পথ খুঁজে পায়। এটি যতটা সম্ভব কমানো আমাদের কাজ। পুনরাবৃত্তিযোগ্য বিল্ডগুলির জন্য দুটি ব্লকার রয়েছে:

• নির্ভরতা - যদি আমরা নির্ভরতার জন্য নির্দিষ্ট সংস্করণ ব্যবহার না করি, এমনকি একটি ছোট পরিবর্তনও আমাদের বিল্ড ভেঙে দিতে পারে।

• ফ্ল্যাকি টেস্ট - কোন স্পষ্ট কারণে মাঝে মাঝে ব্যর্থ হওয়া পরীক্ষাগুলি সবচেয়ে খারাপ।

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

এই স্কিমটি CI-এর জন্য অত্যন্ত গুরুত্বপূর্ণ কারণ এটির ব্যবহার বিল্ডের পুনরাবৃত্তিযোগ্যতাকে উল্লেখযোগ্যভাবে প্রভাবিত করতে পারে যেমন ম্যাভেন দিয়ে আমরা করতে পারি:

 <dependency> <groupId>group</groupId> <artifactId>artifact</artifactId> <version>2.3.1</version> </dependency>

এটি পুনরাবৃত্তিযোগ্যতার জন্য খুব নির্দিষ্ট এবং দুর্দান্ত। যাইহোক, এটি দ্রুত পুরানো হয়ে যেতে পারে। আমরা সংস্করণ নম্বরটি LATEST বা RELEASE দিয়ে প্রতিস্থাপন করতে পারি যা স্বয়ংক্রিয়ভাবে বর্তমান সংস্করণটি পাবে। এটি খারাপ কারণ বিল্ডগুলি আর পুনরাবৃত্তিযোগ্য হবে না।

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

উদাহরণস্বরূপ, সেই আগের ক্ষেত্রে, আমি 2.4.1 নয় বরং 2.3.2 সংস্করণটি নিহিতভাবে ব্যবহার করতে চাই। এটি ক্ষুদ্র নিরাপত্তা আপডেট এবং বাগগুলির জন্য কিছু পুনরাবৃত্তিযোগ্যতা বন্ধ করে দেয়।

কিন্তু একটি ভাল উপায় হল Maven Versions Plugin ব্যবহার করা এবং পর্যায়ক্রমে mvn versions:use-latest-releases কমান্ড ব্যবহার করা। আমাদের প্রকল্প আপ টু ডেট রাখতে এটি সর্বশেষ সংস্করণগুলিকে আপডেট করে৷

এটি পুনরাবৃত্তিযোগ্য বিল্ডগুলির সোজা অংশ। অসুবিধা হল ফ্লাকি পরীক্ষায়। এটি এমন একটি সাধারণ ব্যথা যে কিছু প্রকল্প ব্যর্থ পরীক্ষার একটি "যুক্তিসঙ্গত পরিমাণ" সংজ্ঞায়িত করে এবং কিছু প্রকল্প ব্যর্থতা স্বীকার করার আগে একাধিকবার বিল্ডটি পুনরায় চালায়।

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

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

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

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

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

আমার লক্ষ্য নিখুঁত পরীক্ষা তৈরি করা নয়, এবং তাই আমি বর্ণানুক্রমের মতো ধারাবাহিক ক্রমে পরীক্ষা চালানো পছন্দ করি।

পরীক্ষায় ব্যর্থতার পরিসংখ্যান রাখা গুরুত্বপূর্ণ, এবং কখনোই পুনরায় চেষ্টা চাপবেন না। সমস্যাযুক্ত পরীক্ষাগুলি এবং ব্যর্থতার জন্য কার্যকর করার ক্রম ট্র্যাক করে, আমরা প্রায়শই সমস্যার উত্স খুঁজে পেতে পারি।

বেশিরভাগ সময়, ব্যর্থতার মূল কারণ একটি পূর্বের পরীক্ষায় ত্রুটিপূর্ণ পরিচ্ছন্নতার কারণে ঘটে, যে কারণে অর্ডারটি গুরুত্বপূর্ণ এবং এর ধারাবাহিকতাও গুরুত্বপূর্ণ।

বিকাশকারীর অভিজ্ঞতা এবং সিআই পারফরম্যান্স

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

প্রায়ই, আমি একটি CI চেক পাস করার চেষ্টা করে দিন কাটিয়েছি যাতে আমি আমার পরিবর্তনগুলি একত্রিত করতে পারি। যতবার আমি কাছে আসব, অন্য ডেভেলপার তাদের পরিবর্তনকে প্রথমে একত্রিত করবে এবং আমার বিল্ডকে ভেঙে দেবে।

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

• পরীক্ষায় সদৃশতা হ্রাস করুন - অতি-পরীক্ষা একটি সাধারণ লক্ষণ যা আমরা কভারেজ সরঞ্জামগুলির মাধ্যমে সনাক্ত করতে পারি।

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

• CI প্রক্রিয়ার জন্য অতিরিক্ত বা দ্রুত মেশিন বরাদ্দ করুন।

• CI প্রক্রিয়া সমান্তরাল. আমরা কিছু বিল্ড প্রকার এবং কিছু পরীক্ষা সমান্তরাল করতে পারি।

• প্রকল্পটিকে ছোট প্রকল্পে বিভক্ত করুন - লক্ষ্য করুন যে এটি অগত্যা মাইক্রোসার্ভিস বোঝায় না ।

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

গিটহাব অ্যাকশন

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

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

গিটহাব অ্যাকশনগুলি পরীক্ষা করার জন্য, আমাদের একটি নতুন প্রকল্প দরকার যা এই ক্ষেত্রে, আমি এখানে দেখা কনফিগারেশনের সাথে JHipster ব্যবহার করে তৈরি করেছি:

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

প্রকল্পটি তৈরি হয়ে গেলে, আমরা গিটহাবে প্রকল্প পৃষ্ঠা খুলতে পারি এবং অ্যাকশন ট্যাবে যেতে পারি।

আমরা এই মত কিছু দেখতে হবে:

নীচের ডান কোণায়, আমরা Maven প্রকল্পের ধরন সহ জাভা দেখতে পাচ্ছি। একবার আমরা এই ধরনের বাছাই করলে, আমরা এখানে দেখানো হিসাবে একটি maven.yml ফাইল তৈরিতে চলে যাই:

দুর্ভাগ্যবশত, GitHub দ্বারা প্রস্তাবিত ডিফল্ট maven.yml-এ একটি সমস্যা রয়েছে। এই কোডটি আমরা এই ছবিতে দেখতে পাচ্ছি:

 name: Java CI with Maven on: push: branches: [ "master" ] pull_request: branches: [ "master" ] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Set up JDK 11 uses: actions/setup-java@v3 with: java-version: '11' distribution: 'temurin' cache: maven - name: Build with Maven run: mvn -B package --file pom.xml # Optional: Uploads the full dependency graph to GitHub to improve the quality of Dependabot alerts this repository can receive - name: Update dependency graph uses: advanced-security/maven-dependency-submission-action@571e99aab1055c2e71a1e2309b9691de18d6b7d6

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

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

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

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

সমস্ত YAML ফাইল এবং বিভিন্ন CI স্ট্যাকের কনফিগারেশন সেটিংসের সাথে ডিল করার চেয়ে কখনও কখনও একটি ভাল শেল স্ক্রিপ্ট লেখা সহজ।

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

আমরা এখানে সফল টান অনুরোধ দেখতে পারি:

এটি পরীক্ষা করার জন্য, আমরা “/api” এন্ডপয়েন্টকে “/myapi” এ পরিবর্তন করে কোডে একটি বাগ যোগ করতে পারি। এটি নীচে দেখানো ব্যর্থতা তৈরি করে। এটি কমিটের লেখককে পাঠানো একটি ত্রুটি ইমেলও ট্রিগার করে।

যখন এই ধরনের ব্যর্থতা ঘটে, তখন আমরা ডান পাশের "বিশদ বিবরণ" লিঙ্কে ক্লিক করতে পারি। আপনি এখানে যে ত্রুটি বার্তাটি দেখতে পাচ্ছেন সেটি আমাদের সরাসরি নিয়ে যাবে:

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

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

 @Test @Transactional void testActivateAccount() throws Exception { final String activationKey = "some activation key"; User user = new User(); user.setLogin("activate-account"); user.setEmail("[email protected]"); user.setPassword(RandomStringUtils.randomAlphanumeric(60)); user.setActivated(false); user.setActivationKey(activationKey); userRepository.saveAndFlush(user); restAccountMockMvc.perform(get("/api/activate?key={activationKey}", activationKey)).andExpect(status().isOk()); user = userRepository.findOneByLogin(user.getLogin()).orElse(null); assertThat(user.isActivated()).isTrue(); }

এর মানে দাবী কল ব্যর্থ হয়েছে। isActivated() false ফিরে এসেছে এবং পরীক্ষায় ব্যর্থ হয়েছে। এটি একটি বিকাশকারীকে সমস্যাটি সংকুচিত করতে এবং মূল কারণটি বুঝতে সহায়তা করবে।

অতি

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

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

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

SonarCloud জনপ্রিয় ডেভেলপমেন্ট টুল যেমন GitHub, GitLab, Bitbucket, Azure DevOps এবং আরও অনেক কিছুর সাথে সংহত করে। বিকাশকারীরা তাদের কোডের গুণমান সম্পর্কে রিয়েল-টাইম প্রতিক্রিয়া পেতে এবং সামগ্রিক কোডের গুণমান উন্নত করতে সোনারক্লাউড ব্যবহার করতে পারেন।

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

সোনারক্লাউড এবং সোনারকিউব উভয়ই একই ধরনের কার্যকারিতা প্রদান করে, তবে সোনারক্লাউড একটি ক্লাউড-ভিত্তিক পরিষেবা এবং এর জন্য একটি সাবস্ক্রিপশন প্রয়োজন, যখন সোনারকিউব একটি ওপেন-সোর্স প্ল্যাটফর্ম যা অন-প্রিমিস বা ক্লাউড সার্ভারে ইনস্টল করা যেতে পারে।

সরলতার জন্য, আমরা সোনারক্লাউড ব্যবহার করব কিন্তু সোনারকিউব ঠিকঠাক কাজ করবে। শুরু করতে, আমরা sonarcloud.io- এ যাই এবং সাইন আপ করি। আদর্শভাবে আমাদের GitHub অ্যাকাউন্টের সাথে। তারপরে আমাদের কাছে সোনার ক্লাউড দ্বারা পর্যবেক্ষণের জন্য একটি সংগ্রহস্থল যোগ করার বিকল্প রয়েছে যা এখানে দেখানো হয়েছে:

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

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

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

লক্ষ্য করুন ম্যাভেনের সাথে ব্যবহারের জন্য ডিফল্ট নির্দেশাবলী রয়েছে যা আপনি "Maven" লেবেলযুক্ত বোতামটি ক্লিক করার পরে প্রদর্শিত হবে।

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

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

গিটহাব রিপোজিটরি সিক্রেটস এমন একটি বৈশিষ্ট্য যা ডেভেলপারদেরকে গিটহাব রিপোজিটরির সাথে সম্পর্কিত সংবেদনশীল তথ্য যেমন API কী, টোকেন এবং পাসওয়ার্ডগুলিকে নিরাপদে সংরক্ষণ করতে দেয়, যা সংগ্রহস্থলের দ্বারা ব্যবহৃত বিভিন্ন তৃতীয় পক্ষের পরিষেবা বা প্ল্যাটফর্মগুলিতে অ্যাক্সেসকে প্রমাণীকরণ এবং অনুমোদনের জন্য প্রয়োজনীয়। .

GitHub রিপোজিটরি সিক্রেটসের পিছনে ধারণাটি হল কোড বা কনফিগারেশন ফাইলগুলিতে তথ্য প্রকাশ না করে গোপনীয় তথ্য পরিচালনা এবং ভাগ করার একটি নিরাপদ এবং সুবিধাজনক উপায় প্রদান করা।

গোপনীয়তা ব্যবহার করে, বিকাশকারীরা কোডবেস থেকে সংবেদনশীল তথ্য আলাদা রাখতে পারে এবং নিরাপত্তা লঙ্ঘন বা অননুমোদিত অ্যাক্সেসের ক্ষেত্রে এটিকে প্রকাশ করা বা আপস করা থেকে রক্ষা করতে পারে।

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

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

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

আমাদের এখন এই প্রকল্পে একীভূত করতে হবে। প্রথমে, pom.xml ফাইলে এই দুটি লাইন যোগ করতে হবে। লক্ষ্য করুন যে আপনার নিজের সাথে মেলে প্রতিষ্ঠানের নাম আপডেট করতে হবে। এগুলি XML-এর বিভাগে যাওয়া উচিত:

 <sonar.organization>shai-almog</sonar.organization> <sonar.host.url>https://sonarcloud.io</sonar.host.url>

লক্ষ্য করুন যে আমাদের তৈরি করা JHipster প্রকল্পে ইতিমধ্যেই SonarQube সমর্থন রয়েছে যা এই কোডটি কাজ করার আগে pom ফাইল থেকে সরিয়ে ফেলা উচিত ।

এর পরে, আমরা নিম্নলিখিত সংস্করণের সাথে maven.yml ফাইলের "বিল্ড উইথ ম্যাভেন" অংশটি প্রতিস্থাপন করতে পারি:

 - name: Build with Maven env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # Needed to get PR information, if any SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }} run: mvn -B verify org.sonarsource.scanner.maven:sonar-maven-plugin:sonar -Dsonar.projectKey=shai-almog_HelloJHipster package

একবার আমরা এটি করে ফেললে, সোনারক্লাউড এখানে দেখানো হিসাবে সিস্টেমে একত্রিত হওয়া প্রতিটি পুল অনুরোধের জন্য প্রতিবেদন সরবরাহ করবে:

আমরা একটি প্রতিবেদন দেখতে পাচ্ছি যাতে বাগ, দুর্বলতা, গন্ধ এবং নিরাপত্তা সমস্যাগুলির একটি তালিকা রয়েছে৷ এই সমস্যাগুলির প্রতিটিতে ক্লিক করা আমাদের এইরকম কিছুতে নিয়ে যায়:

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

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

এটি ডুপ্লিকেট কোডও নির্দেশ করে যা ডোন্ট রিপিট ইউরসেলফ (DRY) নীতির লঙ্ঘন নির্দেশ করতে পারে।

অবশেষে

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

এটা আমাদের জীবন সহজ করতে এখানে.

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

এই টুল যে সাহায্য করার কথা ছিল আমাদের নেমেসিস হয়ে যায়। এই ক্ষেত্রে হওয়া উচিত নয়. CI আমাদের জীবনকে সহজ করে তুলবে, অন্যভাবে নয়।