டெவொப்ஸ் லெகோ: பைப்லைனை எப்படி க்யூப்ஸாக அமைத்தோம்

நாங்கள் ஒருமுறை மின்னணு ஆவண மேலாண்மை அமைப்பை ஒரு வாடிக்கையாளருக்கு ஒரு வசதியில் வழங்கினோம். பின்னர் மற்றொரு பொருளுக்கு. மேலும் ஒன்று. மற்றும் நான்காவது, மற்றும் ஐந்தாவது. நாங்கள் 10 விநியோகிக்கப்பட்ட பொருட்களை அடைந்தோம். இது சக்திவாய்ந்ததாக மாறியது... குறிப்பாக மாற்றங்களை நாங்கள் வழங்கும்போது. உற்பத்தி சுற்றுக்கு விநியோகத்தின் ஒரு பகுதியாக, சோதனை முறையின் 5 காட்சிகளுக்கு இறுதியில் 10 மணிநேரம் மற்றும் 6-7 பணியாளர்கள் தேவைப்பட்டனர். இத்தகைய செலவுகள் முடிந்தவரை அரிதாகவே டெலிவரி செய்ய எங்களை கட்டாயப்படுத்தியது. மூன்று வருட செயல்பாட்டிற்குப் பிறகு, எங்களால் அதைத் தாங்க முடியவில்லை, மேலும் ஒரு சிட்டிகை DevOps மூலம் திட்டத்தை மசாலாப்படுத்த முடிவு செய்தோம்.

இப்போது அனைத்து சோதனைகளும் 3 மணி நேரத்தில் நடைபெறுகிறது, அதில் 3 பேர் பங்கேற்கிறார்கள்: ஒரு பொறியாளர் மற்றும் இரண்டு சோதனையாளர்கள். மேம்பாடுகள் எண்ணிக்கையில் தெளிவாக வெளிப்படுத்தப்பட்டு, மிகவும் விரும்பப்படும் TTM குறைவதற்கு வழிவகுக்கும். எங்கள் அனுபவத்தில், DevOps பற்றி அறிந்தவர்களை விட பல வாடிக்கையாளர்கள் பயனடையலாம். எனவே, டெவொப்ஸை மக்களுக்கு நெருக்கமாகக் கொண்டுவர, நாங்கள் ஒரு எளிய கட்டமைப்பாளரை உருவாக்கியுள்ளோம், அதைப் பற்றி இந்த இடுகையில் விரிவாகப் பேசுவோம்.

இப்போது இன்னும் விரிவாகச் சொல்வோம். ஒரு ஆற்றல் நிறுவனம் 10 பெரிய வசதிகளில் ஒரு தொழில்நுட்ப ஆவண மேலாண்மை அமைப்பை வரிசைப்படுத்துகிறது. DevOps இல்லாமல் இந்த அளவிலான திட்டங்களுக்கு வழிசெலுத்துவது எளிதானது அல்ல, ஏனென்றால் கைமுறை உழைப்பின் பெரும்பகுதி வேலையை தாமதப்படுத்துகிறது மற்றும் தரத்தையும் குறைக்கிறது - அனைத்து கைமுறை வேலைகளும் பிழைகள் நிறைந்தவை. மறுபுறம், ஒரே ஒரு நிறுவல் இருக்கும் திட்டங்கள் உள்ளன, ஆனால் எல்லாமே தானாகவே, தொடர்ந்து மற்றும் தோல்வி இல்லாமல் வேலை செய்ய வேண்டும் - எடுத்துக்காட்டாக, பெரிய ஒற்றைக்கல் நிறுவனங்களில் அதே ஆவண ஓட்ட அமைப்புகள். இல்லையெனில், யாரோ அமைப்புகளை கைமுறையாக உருவாக்குவார்கள், வரிசைப்படுத்தல் வழிமுறைகளை மறந்துவிடுவார்கள் - இதன் விளைவாக, உற்பத்தியில் அமைப்புகள் இழக்கப்படும் மற்றும் அனைத்தும் சரிந்துவிடும்.

வழக்கமாக நாங்கள் வாடிக்கையாளருடன் ஒப்பந்தம் மூலம் வேலை செய்கிறோம், இந்த விஷயத்தில் எங்கள் ஆர்வங்கள் சற்று வேறுபடுகின்றன. வாடிக்கையாளர் பட்ஜெட் மற்றும் தொழில்நுட்ப விவரக்குறிப்புகளுக்குள் திட்டத்தை கண்டிப்பாக பார்க்கிறார். தொழில்நுட்ப விவரக்குறிப்புகளில் சேர்க்கப்படாத பல்வேறு DevOps நடைமுறைகளின் நன்மைகளை அவருக்கு விளக்குவது கடினம். கூடுதல் வணிக மதிப்புடன் கூடிய விரைவான வெளியீடுகளில் அல்லது ஒரு ஆட்டோமேஷன் பைப்லைனை உருவாக்குவதில் அவர் ஆர்வமாக இருந்தால் என்ன செய்வது?

ஐயோ, முன்-அங்கீகரிக்கப்பட்ட செலவில் பணிபுரியும் போது, ​​இந்த ஆர்வம் எப்போதும் காணப்படாது. எங்கள் நடைமுறையில், ஒரு நேர்மையற்ற மற்றும் கவனக்குறைவான ஒப்பந்தக்காரரின் வளர்ச்சியை நாங்கள் எடுக்க வேண்டிய ஒரு வழக்கு இருந்தது. இது பயங்கரமானது: புதுப்பித்த மூலக் குறியீடுகள் எதுவும் இல்லை, வெவ்வேறு நிறுவல்களில் ஒரே அமைப்பின் குறியீட்டு அடிப்படை வேறுபட்டது, ஆவணங்கள் ஓரளவு இல்லை, மற்றும் ஓரளவு பயங்கரமான தரம். நிச்சயமாக, வாடிக்கையாளருக்கு மூலக் குறியீடு, அசெம்பிளி, வெளியீடுகள் போன்றவற்றின் மீது கட்டுப்பாடு இல்லை.

இதுவரை, அனைவருக்கும் DevOps பற்றி தெரியாது, ஆனால் அதன் நன்மைகள் பற்றி, உண்மையான வள சேமிப்பு பற்றி பேசினால், அனைத்து வாடிக்கையாளர்களின் கண்களும் ஒளிரும். எனவே DevOps உள்ளிட்ட கோரிக்கைகளின் எண்ணிக்கை காலப்போக்கில் அதிகரித்து வருகிறது. இங்கே, வாடிக்கையாளர்களுடன் ஒரே மொழியை எளிதாகப் பேச, வணிகச் சிக்கல்கள் மற்றும் DevOps நடைமுறைகளை விரைவாக இணைக்க வேண்டும், இது பொருத்தமான மேம்பாட்டுக் குழாய்களை உருவாக்க உதவும்.

எனவே, எங்களிடம் ஒருபுறம் சிக்கல்கள் உள்ளன, மறுபுறம் DevOps அறிவு, நடைமுறைகள் மற்றும் கருவிகள் உள்ளன. அனுபவத்தை ஏன் அனைவருடனும் பகிர்ந்து கொள்ளக்கூடாது?

DevOps கட்டமைப்பாளரை உருவாக்குதல்

சுறுசுறுப்பானது அதன் சொந்த அறிக்கையைக் கொண்டுள்ளது. ஐடிஐஎல் அதன் சொந்த முறையைக் கொண்டுள்ளது. DevOps குறைவான அதிர்ஷ்டம் கொண்டது - இது இன்னும் வார்ப்புருக்கள் மற்றும் தரநிலைகளைப் பெறவில்லை. இருந்தாலும் சில முயற்சி செய்கிறார்கள் நிறுவனங்களின் வளர்ச்சி மற்றும் செயல்பாட்டு நடைமுறைகளின் மதிப்பீட்டின் அடிப்படையில் நிறுவனங்களின் முதிர்ச்சியை தீர்மானிக்கவும்.

அதிர்ஷ்டவசமாக, 2014 இல் நன்கு அறியப்பட்ட நிறுவனம் கார்ட்னர் சேகரிக்கப்பட்டது மற்றும் முக்கிய DevOps நடைமுறைகள் மற்றும் அவற்றுக்கிடையேயான உறவுகளை பகுப்பாய்வு செய்தது. இதன் அடிப்படையில், நான் ஒரு விளக்கப்படத்தை வெளியிட்டேன்:

நாங்கள் அதை அடிப்படையாக எடுத்துக் கொண்டோம் வடிவமைப்பாளர். நான்கு பகுதிகளில் ஒவ்வொன்றும் கருவிகளின் தொகுப்பைக் கொண்டுள்ளன - நாங்கள் அவற்றை ஒரு தரவுத்தளத்தில் சேகரித்தோம், மிகவும் பிரபலமானவற்றை அடையாளம் கண்டோம், ஒருங்கிணைப்பு புள்ளிகள் மற்றும் பொருத்தமான தேர்வுமுறை வழிமுறைகளை அடையாளம் கண்டோம். மொத்தத்தில் அது மாறியது 36 நடைமுறைகள் மற்றும் 115 கருவிகள், இதில் கால் பகுதி திறந்த மூல அல்லது இலவச மென்பொருள். அடுத்து, ஒவ்வொரு பகுதியிலும் நாம் என்ன சாதித்துள்ளோம் என்பதைப் பற்றி பேசுவோம், உதாரணமாக, தொழில்நுட்ப ஆவண நிர்வாகத்தை உருவாக்கும் திட்டத்தில் இது எவ்வாறு செயல்படுத்தப்பட்டது என்பது பற்றி, நாங்கள் இடுகையைத் தொடங்கினோம்.

செயல்முறைகள்

மோசமான EDMS திட்டத்தில், தொழில்நுட்ப ஆவண மேலாண்மை அமைப்பு 10 பொருள்களில் ஒவ்வொன்றிலும் அதே திட்டத்தின் படி பயன்படுத்தப்பட்டது. நிறுவலில் 4 சேவையகங்கள் உள்ளன: தரவுத்தள சேவையகம், பயன்பாட்டு சேவையகம், முழு உரை அட்டவணைப்படுத்தல் மற்றும் உள்ளடக்க மேலாண்மை. நிறுவலில், அவை ஒற்றை முனைக்குள் இயங்குகின்றன மற்றும் வசதிகளில் உள்ள தரவு மையத்தில் அமைந்துள்ளன. அனைத்து பொருட்களும் உள்கட்டமைப்பில் சிறிது வேறுபடுகின்றன, ஆனால் இது உலகளாவிய தொடர்புகளில் தலையிடாது.

முதலில், DevOps நடைமுறைகளின்படி, உள்கட்டமைப்பை உள்நாட்டில் தானியக்கமாக்கினோம், பின்னர் டெலிவரியை சோதனைச் சுற்றுக்குக் கொண்டு வந்தோம், பின்னர் வாடிக்கையாளரின் தயாரிப்புக்கு. ஒவ்வொரு செயல்முறையும் படிப்படியாக வேலை செய்யப்பட்டது. சுற்றுச்சூழல் அமைப்புகள் மூலக் குறியீடு அமைப்பில் சரி செய்யப்படுகின்றன, தானியங்கு புதுப்பித்தலுக்காக எந்த விநியோக கிட் தொகுக்கப்பட்டுள்ளது என்பதைக் கணக்கில் எடுத்துக்கொள்கிறது. உள்ளமைவு மாற்றங்கள் ஏற்பட்டால், பொறியாளர்கள் பதிப்பு கட்டுப்பாட்டு அமைப்பில் பொருத்தமான மாற்றங்களைச் செய்ய வேண்டும் - பின்னர் தானியங்கி புதுப்பிப்பு சிக்கல்கள் இல்லாமல் நடைபெறும்.

இந்த அணுகுமுறைக்கு நன்றி, சோதனை செயல்முறை பெரிதும் எளிமைப்படுத்தப்பட்டுள்ளது. முன்னதாக, ஸ்டாண்டுகளை கைமுறையாக புதுப்பிப்பதைத் தவிர வேறு எதையும் செய்யாத சோதனையாளர்கள் இந்த திட்டத்தில் இருந்தனர். இப்போது அவர்கள் வருகிறார்கள், எல்லாம் செயல்படுவதைப் பார்த்து மேலும் பயனுள்ள விஷயங்களைச் செய்யுங்கள். ஒவ்வொரு புதுப்பிப்பும் தானாகவே சோதிக்கப்படும் - மேற்பரப்பு மட்டத்திலிருந்து வணிக சூழ்நிலை ஆட்டோமேஷன் வரை. முடிவுகள் TestRail இல் தனித்தனி அறிக்கைகளாக வெளியிடப்படுகின்றன.

கலாச்சாரம்

சோதனை வடிவமைப்பின் உதாரணம் மூலம் தொடர்ச்சியான பரிசோதனை சிறப்பாக விளக்கப்படுகிறது. இதுவரை இல்லாத அமைப்பைச் சோதிப்பது ஆக்கப்பூர்வமான வேலை. ஒரு சோதனைத் திட்டத்தை எழுதும் போது, ​​எப்படிச் சரியாகச் சோதிக்க வேண்டும், எந்தக் கிளைகளைப் பின்பற்ற வேண்டும் என்பதை நீங்கள் புரிந்து கொள்ள வேண்டும். மேலும் காசோலைகளின் உகந்த எண்ணிக்கையைத் தீர்மானிக்க நேரம் மற்றும் பட்ஜெட்டுக்கு இடையே சமநிலையைக் கண்டறியவும். தேவையான சோதனைகளை சரியாகத் தேர்ந்தெடுப்பது முக்கியம், பயனர் கணினியுடன் எவ்வாறு தொடர்புகொள்வார் என்பதைப் பற்றி சிந்தியுங்கள், சுற்றுச்சூழல் மற்றும் சாத்தியமான வெளிப்புற காரணிகளை கணக்கில் எடுத்துக் கொள்ளுங்கள். தொடர்ச்சியான சோதனை இல்லாமல் செய்ய முடியாது.

இப்போது தொடர்பு கலாச்சாரம் பற்றி. முன்னதாக, இரண்டு எதிர் பக்கங்கள் இருந்தன - பொறியாளர்கள் மற்றும் டெவலப்பர்கள். டெவலப்பர்கள் கூறியதாவது: "இது எவ்வாறு தொடங்கப்படும் என்பது எங்களுக்கு கவலையில்லை. நீங்கள் பொறியியலாளர்கள், நீங்கள் புத்திசாலி, அது தோல்வியின்றி செயல்படுவதை உறுதிப்படுத்திக் கொள்ளுங்கள்". பொறியாளர்கள் பதிலளித்தனர்: "நீங்கள் டெவலப்பர்கள் மிகவும் கவனக்குறைவாக இருக்கிறீர்கள். மிகவும் கவனமாக இருப்போம், உங்கள் வெளியீடுகளை குறைவாகவே இயக்குவோம். ஏனென்றால் ஒவ்வொரு முறையும் நீங்கள் எங்களுக்கு ஒரு கசிவு குறியீட்டைக் கொடுக்கும்போது, ​​எப்படி தொடர்புகொள்வது என்பது எங்களுக்குத் தெளிவாகத் தெரியவில்லை.. இது DevOps கண்ணோட்டத்தில் இருந்து வித்தியாசமாக கட்டமைக்கப்பட்ட ஒரு கலாச்சார தொடர்பு பிரச்சினை. இங்கே, பொறியாளர்கள் மற்றும் டெவலப்பர்கள் இருவரும் ஒரே குழுவின் ஒரு பகுதியாக உள்ளனர், இது தொடர்ந்து மாறுவதில் கவனம் செலுத்துகிறது, ஆனால் அதே நேரத்தில் நம்பகமான மென்பொருள்.

ஒரே குழுவிற்குள், நிபுணர்கள் ஒருவருக்கொருவர் உதவுவதில் உறுதியாக உள்ளனர். முன்பு இருந்தது போல்? எடுத்துக்காட்டாக, சுமார் 50 பக்கங்கள் கொண்ட சில தடிமனான வரிசைப்படுத்தல் வழிமுறைகள் தயாராகிக் கொண்டிருந்தன. பொறியாளர் அதைப் படித்தார், ஒன்று புரியவில்லை, சபித்துவிட்டு, விடியற்காலை மூன்று மணியளவில் டெவலப்பரிடம் கருத்துச் சொல்லும்படி கேட்டார். டெவலப்பர் கருத்து தெரிவித்தார் மற்றும் சபித்தார் - இறுதியில், யாரும் மகிழ்ச்சியாக இல்லை. கூடுதலாக, இயற்கையாகவே, சில தவறுகள் இருந்தன, ஏனென்றால் வழிமுறைகளில் உள்ள அனைத்தையும் நீங்கள் நினைவில் கொள்ள முடியாது. இப்போது பொறியாளர், டெவலப்பருடன் சேர்ந்து, பயன்பாட்டு மென்பொருள் உள்கட்டமைப்பின் தானியங்கி வரிசைப்படுத்தலுக்கான ஸ்கிரிப்டை எழுதுகிறார். அவர்கள் ஒருவருக்கொருவர் நடைமுறையில் ஒரே மொழியில் பேசுகிறார்கள்.

மக்கள்

புதுப்பித்தலின் நோக்கத்தால் அணியின் அளவு தீர்மானிக்கப்படுகிறது. டெலிவரி உருவாக்கத்தின் போது குழு ஆட்சேர்ப்பு செய்யப்படுகிறது; பொது திட்டக் குழுவிலிருந்து ஆர்வமுள்ளவர்களும் இதில் அடங்குவர். ஒவ்வொரு கட்டத்திற்கும் பொறுப்பானவர்களுடன் புதுப்பிப்புத் திட்டம் எழுதப்படுகிறது, மேலும் அது முன்னேறும்போது குழு அறிக்கை செய்கிறது. அனைத்து குழு உறுப்பினர்களும் ஒன்றுக்கொன்று மாறக்கூடியவர்கள். குழுவின் ஒரு பகுதியாக, எங்களிடம் ஒரு காப்புப்பிரதி டெவலப்பர் இருக்கிறார், ஆனால் அவர் கிட்டத்தட்ட இணைக்க வேண்டியதில்லை.

தொழில்நுட்பம்

தொழில்நுட்ப வரைபடத்தில், சில புள்ளிகள் முன்னிலைப்படுத்தப்பட்டுள்ளன, ஆனால் அவற்றின் கீழ் தொழில்நுட்பங்கள் உள்ளன - அவற்றின் விளக்கங்களுடன் ஒரு முழு புத்தகத்தையும் நீங்கள் வெளியிடலாம். எனவே நாங்கள் மிகவும் சுவாரஸ்யமானவற்றை முன்னிலைப்படுத்துவோம்.

குறியீட்டாக உள்கட்டமைப்பு

இப்போது, ​​அநேகமாக, இந்த கருத்து யாரையும் ஆச்சரியப்படுத்தாது, ஆனால் முன்னர் உள்கட்டமைப்புகளின் விளக்கங்கள் விரும்பத்தக்கதாக இருந்தன. பொறியாளர்கள் திகிலுடன் அறிவுறுத்தல்களைப் பார்த்தனர், சோதனைச் சூழல்கள் தனித்தன்மை வாய்ந்தவை, அவை நேசத்துக்குரியவை மற்றும் போற்றப்பட்டன, தூசித் துகள்கள் அவற்றிலிருந்து வீசப்பட்டன.

இப்போதெல்லாம் பரிசோதனைக்கு யாரும் பயப்படுவதில்லை. மெய்நிகர் இயந்திரங்களின் அடிப்படை படங்கள் உள்ளன, சூழல்களை வரிசைப்படுத்துவதற்கான ஆயத்த காட்சிகள் உள்ளன. அனைத்து டெம்ப்ளேட்கள் மற்றும் ஸ்கிரிப்ட்கள் பதிப்பு கட்டுப்பாட்டு அமைப்பில் சேமிக்கப்பட்டு உடனடியாக புதுப்பிக்கப்படும். முன்னதாக, ஒரு ஸ்டாண்டிற்கு ஒரு தொகுப்பை வழங்க வேண்டிய அவசியம் ஏற்பட்டபோது, ​​ஒரு கட்டமைப்பு இடைவெளி தோன்றியது. இப்போது நீங்கள் மூலக் குறியீட்டில் ஒரு வரியைச் சேர்க்க வேண்டும்.

உள்கட்டமைப்பு ஸ்கிரிப்டுகள் மற்றும் பைப்லைன்களுக்கு கூடுதலாக, ஆவணப்படுத்தல் ஒரு குறியீட்டு அணுகுமுறையாக ஆவணப்படுத்தலுக்கும் பயன்படுத்தப்படுகிறது. இதற்கு நன்றி, புதிய நபர்களை திட்டத்துடன் இணைப்பது எளிதானது, விவரிக்கப்பட்ட செயல்பாடுகளின் அடிப்படையில் அவர்களை கணினியில் அறிமுகப்படுத்துவது, எடுத்துக்காட்டாக, சோதனைத் திட்டத்தில், மேலும் சோதனை நிகழ்வுகளை மீண்டும் பயன்படுத்தவும்.

தொடர்ச்சியான விநியோகம் மற்றும் கண்காணிப்பு

முந்தைய கட்டுரையில் DevOps பற்றி, தொடர்ச்சியான விநியோகம் மற்றும் கண்காணிப்பை செயல்படுத்துவதற்கான கருவிகளை நாங்கள் எவ்வாறு தேர்ந்தெடுத்தோம் என்பதைப் பற்றி பேசினோம். பெரும்பாலும் எதையும் மீண்டும் எழுத வேண்டிய அவசியமில்லை - முன்பு எழுதப்பட்ட ஸ்கிரிப்ட்களைப் பயன்படுத்தவும், கூறுகளுக்கு இடையில் ஒருங்கிணைப்பை சரியாக உருவாக்கவும் மற்றும் பொதுவான மேலாண்மை கன்சோலை உருவாக்கவும் போதுமானது. ஒரு பொத்தான் அல்லது அட்டவணையைப் பயன்படுத்தி அனைத்து செயல்முறைகளையும் தொடங்கலாம்.

ஆங்கிலத்தில் பல்வேறு கருத்துக்கள் உள்ளன, தொடர்ச்சியான விநியோகம் மற்றும் தொடர்ச்சியான வரிசைப்படுத்தல். இரண்டையும் "தொடர்ச்சியான விநியோகம்" என்று மொழிபெயர்க்கலாம், ஆனால் உண்மையில் அவற்றுக்கிடையே ஒரு சிறிய வித்தியாசம் உள்ளது. விநியோகிக்கப்பட்ட எரிசக்தி நிறுவனத்தின் தொழில்நுட்ப ஆவண ஓட்டத்திற்கான எங்கள் திட்டத்தில், டெலிவரி பயன்படுத்தப்படுகிறது - உற்பத்திக்கான நிறுவல் கட்டளையின் மீது நிகழும்போது. வரிசைப்படுத்தலில், நிறுவல் தானாகவே நிகழும். இந்த திட்டத்தில் தொடர்ச்சியான டெலிவரி பொதுவாக மாறிவிட்டது DevOps இன் மையப் பகுதி.

பொதுவாக, சில அளவுருக்களை சேகரிப்பதன் மூலம், DevOps நடைமுறைகள் ஏன் பயனுள்ளதாக இருக்கும் என்பதை நீங்கள் தெளிவாக புரிந்து கொள்ளலாம். எண்களை உண்மையில் விரும்பும் நிர்வாகத்திற்கு இதைத் தெரிவிக்கவும். வெளியீடுகளின் மொத்த எண்ணிக்கை, ஸ்கிரிப்ட் நிலைகளின் செயல்பாட்டு நேரம், வெற்றிகரமான வெளியீடுகளின் பங்கு - இவை அனைத்தும் சந்தைக்கு அனைவருக்கும் பிடித்த நேரத்தை நேரடியாக பாதிக்கிறது, அதாவது, பதிப்பு கட்டுப்பாட்டு அமைப்புக்கான உறுதிப்பாட்டிலிருந்து ஒரு பதிப்பை வெளியிடும் நேரம் உற்பத்தி சூழல். தேவையான கருவிகளை செயல்படுத்துவதன் மூலம், பொறியாளர்கள் மதிப்புமிக்க குறிகாட்டிகளை அஞ்சல் மூலம் பெறுகிறார்கள், மேலும் திட்ட மேலாளர் அவற்றை டாஷ்போர்டில் பார்க்கிறார். இந்த வழியில் நீங்கள் உடனடியாக புதிய கருவிகளின் நன்மைகளை மதிப்பீடு செய்யலாம். DevOps வடிவமைப்பாளரைப் பயன்படுத்தி உங்கள் உள்கட்டமைப்பில் அவற்றை முயற்சி செய்யலாம்.

யாருக்கு நமது தேவை இருக்கும் DevOps வடிவமைப்பாளர்?

பாசாங்கு செய்ய வேண்டாம்: ஆரம்பத்தில், அவர் நமக்கு பயனுள்ளதாக மாறினார். நாங்கள் ஏற்கனவே கூறியது போல், நீங்கள் வாடிக்கையாளருடன் அதே மொழியைப் பேச வேண்டும், மேலும் DevOps வடிவமைப்பாளரின் உதவியுடன் அத்தகைய உரையாடலுக்கான அடிப்படையை விரைவாக வரையலாம். வணிக வல்லுநர்கள் தங்களுக்குத் தேவையானதைத் தாங்களாகவே மதிப்பிட முடியும், இதனால் வேகமாக வளர்ச்சியடைவார்கள். வடிவமைப்பாளரை முடிந்தவரை விரிவாக உருவாக்க முயற்சித்தோம், பல விளக்கங்களைச் சேர்ப்பதன் மூலம், எந்தவொரு பயனரும் அவர் எதைத் தேர்வு செய்கிறார் என்பதைப் புரிந்துகொள்வார்கள்.

வடிவமைப்பாளரின் வடிவம், கட்டுமான செயல்முறைகள் மற்றும் ஆட்டோமேஷனில் நிறுவனத்தின் தற்போதைய முன்னேற்றங்களை கணக்கில் எடுத்துக்கொள்ள உங்களை அனுமதிக்கிறது. ஏற்கனவே உள்ள செயல்முறைகளுடன் நன்றாக ஒருங்கிணைத்து, வெறுமனே இடைவெளிகளை நிரப்பக்கூடிய தீர்வுகளை மட்டுமே நீங்கள் தேர்வு செய்ய முடிந்தால், எல்லாவற்றையும் கிழித்து மீண்டும் உருவாக்க வேண்டிய அவசியமில்லை.

ஒருவேளை உங்கள் வளர்ச்சி ஏற்கனவே உயர்ந்த நிலைக்கு நகர்ந்திருக்கலாம், மேலும் எங்கள் கருவி மிகவும் "கேப்டனாக" தோன்றும். ஆனால் அது நமக்கே பயனுள்ளதாக இருக்கும் என்றும், வாசகர்கள் சிலருக்கு இது பயனுள்ளதாக இருக்கும் என்றும் நம்புகிறோம். நாங்கள் உங்களுக்கு நினைவூட்டுகிறோம் இணைப்பை வடிவமைப்பாளருக்கு - ஏதேனும் இருந்தால், ஆரம்ப தரவை உள்ளிட்ட உடனேயே வரைபடத்தைப் பெறுவீர்கள். உங்கள் கருத்து மற்றும் சேர்த்தல்களுக்கு நாங்கள் நன்றியுள்ளவர்களாக இருப்போம்.

ஆதாரம்: www.habr.com