API ডেভেলপমেন্ট লাইফসাইকেল

আপনি Apigee Edge ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন দেখুন। তথ্য

প্রতিটি সংস্থার অনন্য সফটওয়্যার ডেভেলপমেন্ট লাইফসাইকেল (SDLC) থাকে। অন্যান্য অ্যাপ্লিকেশন ডেভেলপ, পরীক্ষা ও ডেপ্লয় করার জন্য আপনি আজ যেসব প্রসেস ব্যবহার করেন, API প্রক্সি ডেপ্লয়মেন্টকে সেইসব প্রসেসের সাথে সিঙ্ক্রোনাইজ ও অ্যালাইন করা প্রায়ই প্রয়োজন হয়।

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

API পরিষেবা API-এর ডকুমেন্টেশন API রেফারেন্সে দেওয়া আছে। API রেফারেন্স থেকে শুরু করা দেখুন।

পরিবেশ

Apigee Edge-এ প্রতিটি সংস্থার কমপক্ষে দুটি করে ডিপ্লয়মেন্ট এনভায়রনমেন্ট থাকে যা API প্রক্সি করার জন্য উপলভ্য: 'test' ও 'prod'। দুটি এনভায়রনমেন্টের মধ্যে পার্থক্যটি স্বেচ্ছাকৃত — প্রতিটি এনভায়রনমেন্টকে নেটওয়ার্ক অ্যাড্রেসের (URL) আলাদা আলাদা সেট দিয়ে শনাক্ত করা হয়। API এক্সটার্নাল ডেভেলপারদের কাছে প্রকাশ করার আগে, API প্রক্সি তৈরি ও যাচাই করার জন্য আপনাকে একটি ডোমেন প্রদান করাই হল লক্ষ্য।

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

ইনবাউন্ডের ক্ষেত্রে, প্রতিটি এনভায়রনমেন্টের জন্য সার্ভার TLS/SSL অটোমেটিক চালু হয়ে যায়। দুটি VirtualHost প্রতিটি এনভায়রনমেন্টে আগে থেকেই সংজ্ঞায়িত করা আছে: default এবং secure। ডিফল্ট একটি HTTP অ্যাড্রেসকে সংজ্ঞায়িত করে, যেখানে সুরক্ষিত একটি HTTP/S অ্যাড্রেসকে সংজ্ঞায়িত করে, যার মধ্যে আগে থেকে কনফিগার করা সার্ভার-সাইড TLS/SSL থাকে। API প্রক্সি কনফিগারেশনে, ProxyEndpoint কোন VirtualHosts-এ শুনবে তা আপনি উল্লেখ করেন। প্রোডাকশনে প্রমোট করার সময়, আপনি সাধারণত API প্রক্সি কনফিগারেশন থেকে default VirtualHost সরিয়ে দিয়ে HTTP বন্ধ করে দেন।

যেমন, নিম্নলিখিত ProxyEndpoint HTTP ও HTTPS-এ শোনে।

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>default</VirtualHost>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

ProxyEndpoint কনফিগারেশন থেকে default VirtualHost মুছে দিয়ে, আপনি এমন API প্রক্সি তৈরি করেন যা শুধুমাত্র HTTPS-এ শোনে, HTTP-তে নয়।

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

ম্যানেজমেন্ট UI-এর মূল মেনু থেকে এনভায়রনমেন্ট বিকল্প বেছে নিয়ে আপনি দেখতে পাবেন যে কোন কোন VirtualHost কোনও এনভায়রনমেন্টে উপলভ্য।

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

এনভায়রনমেন্টে API প্রক্সি ডেপ্লয় করা

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

আরও তথ্যের জন্য, ডেপ্লয়মেন্ট বোঝা দেখুন।

টেস্টের মধ্যে আইটেরেটিভ ডেভেলপমেন্ট

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

প্রোডাকশন এনভায়রনমেন্টে প্রোমোশন

কোনও API প্রক্সি সম্পূর্ণরূপে প্রয়োগ ও পরীক্ষা করা হয়ে গেলে, সেটি 'প্রোডাকশন' এনভায়রনমেন্টে প্রমোট করার জন্য রেডি হয়ে যায়। পরীক্ষার জন্য API প্রক্সি-তে করা পরিবর্তন, প্রোডাকশনে ডিপ্লয় করা API প্রক্সি-তে করা পরিবর্তনকে ওভাররাইট করতে ব্যবহার করা হবে।

API প্রক্সি নির্বিঘ্নে ডেপ্লয় করা নিশ্চিত করতে API পরিষেবা বিভিন্ন সুবিধা প্রদান করে। এর ফলে, ডেপ্লয়মেন্ট প্রসেস চলাকালীন অ্যাপ ও গ্রাহকদের উপর প্রভাব কম পড়ে।

স্ক্রিপ্টিং ডিপ্লয়মেন্ট

Apigee Edge ম্যানেজমেন্ট UI আপনাকে API প্রক্সি বিল্ডার থেকে সরাসরি প্রোডাকশনে API প্রক্সি ডিপ্লয় করতে দেয়। তবে, অনেক ক্ষেত্রে নিরাপত্তা, নির্ভরযোগ্যতা এবং ধারাবাহিকতার প্রয়োজনীয়তা ডেভেলপমেন্ট টিমকে ডিপ্লয়মেন্ট প্রসেস স্ক্রিপ্ট করার জন্য বাধ্য করবে। এটি করতে, আপনি API পরিষেবার মাধ্যমে প্রকাশ করা RESTful API-কে ইনভোক করে এমন কোড ও স্ক্রিপ্ট লিখতে পারেন।

পরিবেশগত রিসোর্স

প্রোমোশনের সময় অতিরিক্ত কন্ট্রোলের জন্য, সাজেস্ট করা হয় যে আপনি শুধুমাত্র টেস্টে API প্রক্সি নিয়ে কাজ করুন এবং প্রোডাকশনে ডিপ্লয় করা API প্রক্সিতে যত কম সম্ভব পরিবর্তন করুন।

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

• টার্গেট URL: API প্রক্সি সাধারণত টেস্টিং ও প্রোডাকশন চলাকালীন আলাদা আলাদা ব্যাকএন্ড URL কল করে। আপনি এনভায়রনমেন্ট-নিরপেক্ষ TargetEndpoint কনফিগারেশন তৈরি করতে TargetServer কনফিগারেশন ব্যবহার করতে পারবেন। ব্যাকএন্ড সার্ভার জুড়ে লোড ব্যালেন্সিং দেখুন।
• ক্যাশে ও কী/ভ্যালু ম্যাপ: উভয় পারসিস্টেন্স রিসোর্সই এনভায়রনমেন্টের মাধ্যমে স্কোপ করা হয়। আপনাকে নিশ্চিত করতে হবে যে প্রোমোশনের সময় কনফিগারেশনে পরিবর্তন করার প্রয়োজন ছাড়াই ডেটা স্টোর করার জন্য API প্রক্সি চালু করতে নামকরণ কনভেনশন ব্যবহার করা হয়েছে। দেখুন এনভায়র্নমেন্ট ক্যাশে তৈরি ও এডিট করা।
• ServiceCallout টার্গেট: Service callout, এনভায়রনমেন্টের উপর নির্ভর করে বিভিন্ন টার্গেট ব্যবহার করতে পারে। যেমন, টেস্ট এনভায়রনমেন্টে কোনও ServiceCallout যদি কোনও ডেমো পরিষেবা ব্যবহার করে। পরিষেবা কলআউট নীতি দেখুন।

API প্রক্সি কনফিগারেশনকে এনভায়রনমেন্ট-নিরপেক্ষ করতে, আপনি কন্ডিশনাল স্টেটমেন্টও ব্যবহার করতে পারেন। environment.name ভেরিয়েবল দিয়ে তৈরি কন্ডিশনাল স্টেটমেন্ট কোনও নীতি প্রয়োগ করার আগে বা ব্যাকএন্ডে কোনও URL-এ রাউটিং করার আগে বর্তমান এনভায়রনমেন্ট মূল্যায়ন করতে ব্যবহার করা যেতে পারে।

আরও তথ্যের জন্য, ডেপ্লয়মেন্ট বোঝা দেখুন।