ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳಿಂದ ನಮ್ಮದೇ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗೆ: CIAN ನಲ್ಲಿ ನಾವು ಅಭಿವೃದ್ಧಿಯನ್ನು ಹೇಗೆ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಿದ್ದೇವೆ

RIT 2019 ರಲ್ಲಿ, ನಮ್ಮ ಸಹೋದ್ಯೋಗಿ ಅಲೆಕ್ಸಾಂಡರ್ ಕೊರೊಟ್ಕೊವ್ ಮಾಡಿದರು ವರದಿ CIAN ನಲ್ಲಿ ಅಭಿವೃದ್ಧಿಯ ಯಾಂತ್ರೀಕರಣದ ಬಗ್ಗೆ: ಜೀವನ ಮತ್ತು ಕೆಲಸವನ್ನು ಸರಳಗೊಳಿಸಲು, ನಾವು ನಮ್ಮದೇ ಆದ ಇಂಟೆಗ್ರೊ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಇದು ಕಾರ್ಯಗಳ ಜೀವನ ಚಕ್ರವನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತದೆ, ವಾಡಿಕೆಯ ಕಾರ್ಯಾಚರಣೆಗಳ ಡೆವಲಪರ್‌ಗಳನ್ನು ನಿವಾರಿಸುತ್ತದೆ ಮತ್ತು ಉತ್ಪಾದನೆಯಲ್ಲಿನ ದೋಷಗಳ ಸಂಖ್ಯೆಯನ್ನು ಗಣನೀಯವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಈ ಪೋಸ್ಟ್‌ನಲ್ಲಿ, ಅಲೆಕ್ಸಾಂಡರ್‌ನ ವರದಿಯನ್ನು ನಾವು ಪೂರಕಗೊಳಿಸುತ್ತೇವೆ ಮತ್ತು ನಾವು ಸರಳ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳಿಂದ ನಮ್ಮ ಸ್ವಂತ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಮೂಲಕ ತೆರೆದ ಮೂಲ ಉತ್ಪನ್ನಗಳನ್ನು ಸಂಯೋಜಿಸಲು ಹೇಗೆ ಹೋಗಿದ್ದೇವೆ ಮತ್ತು ನಮ್ಮ ಪ್ರತ್ಯೇಕ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ತಂಡವು ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ನಿಮಗೆ ತಿಳಿಸುತ್ತೇವೆ.
 

ಶೂನ್ಯ ಮಟ್ಟ

"ಶೂನ್ಯ ಮಟ್ಟ ಎಂದು ಏನೂ ಇಲ್ಲ, ನನಗೆ ಅಂತಹ ವಿಷಯ ತಿಳಿದಿಲ್ಲ"
"ಕುಂಗ್ ಫೂ ಪಾಂಡಾ" ಚಿತ್ರದ ಮಾಸ್ಟರ್ ಶಿಫು

ಕಂಪನಿಯು ಸ್ಥಾಪನೆಯಾದ 14 ವರ್ಷಗಳ ನಂತರ CIAN ನಲ್ಲಿ ಆಟೋಮೇಷನ್ ಪ್ರಾರಂಭವಾಯಿತು. ಆಗ ಅಭಿವೃದ್ಧಿ ತಂಡದಲ್ಲಿ 35 ಮಂದಿ ಇದ್ದರು. ನಂಬಲು ಕಷ್ಟ, ಸರಿ? ಸಹಜವಾಗಿ, ಯಾಂತ್ರೀಕೃತಗೊಂಡವು ಕೆಲವು ರೂಪದಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ, ಆದರೆ ನಿರಂತರ ಏಕೀಕರಣ ಮತ್ತು ಕೋಡ್ ವಿತರಣೆಗಾಗಿ ಪ್ರತ್ಯೇಕ ನಿರ್ದೇಶನವು 2015 ರಲ್ಲಿ ರೂಪುಗೊಂಡಿತು. 

ಆ ಸಮಯದಲ್ಲಿ, ನಾವು Linux/Windows ಸರ್ವರ್‌ಗಳಲ್ಲಿ ನಿಯೋಜಿಸಲಾದ ಪೈಥಾನ್, C# ಮತ್ತು PHP ಯ ಬೃಹತ್ ಏಕಶಿಲೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಈ ದೈತ್ಯನನ್ನು ನಿಯೋಜಿಸಲು, ನಾವು ಹಸ್ತಚಾಲಿತವಾಗಿ ರನ್ ಮಾಡಿದ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳ ಸೆಟ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಏಕಶಿಲೆಯ ಜೋಡಣೆಯು ಸಹ ಇತ್ತು, ಇದು ಶಾಖೆಗಳನ್ನು ವಿಲೀನಗೊಳಿಸುವಾಗ, ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸುವಾಗ ಮತ್ತು "ನಿರ್ಮಾಣದಲ್ಲಿ ವಿಭಿನ್ನವಾದ ಕಾರ್ಯಗಳೊಂದಿಗೆ" ಮರುನಿರ್ಮಾಣ ಮಾಡುವಾಗ ಘರ್ಷಣೆಗಳಿಂದಾಗಿ ನೋವು ಮತ್ತು ಸಂಕಟವನ್ನು ತಂದಿತು. ಸರಳೀಕೃತ ಪ್ರಕ್ರಿಯೆಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

ನಮಗೆ ಇದರಿಂದ ಸಂತೋಷವಾಗಲಿಲ್ಲ ಮತ್ತು ನಾವು ಪುನರಾವರ್ತನೀಯ, ಸ್ವಯಂಚಾಲಿತ ಮತ್ತು ನಿರ್ವಹಿಸಬಹುದಾದ ನಿರ್ಮಾಣ ಮತ್ತು ನಿಯೋಜನೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿರ್ಮಿಸಲು ಬಯಸಿದ್ದೇವೆ. ಇದಕ್ಕಾಗಿ, ನಮಗೆ CI/CD ಸಿಸ್ಟಮ್ ಅಗತ್ಯವಿದೆ, ಮತ್ತು ನಾವು ಟೀಮ್‌ಸಿಟಿಯ ಉಚಿತ ಆವೃತ್ತಿ ಮತ್ತು ಜೆಂಕಿನ್ಸ್‌ನ ಉಚಿತ ಆವೃತ್ತಿಯ ನಡುವೆ ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ, ಏಕೆಂದರೆ ನಾವು ಅವರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಎರಡೂ ಕಾರ್ಯಗಳ ಸೆಟ್‌ನ ವಿಷಯದಲ್ಲಿ ನಮಗೆ ಸೂಕ್ತವಾಗಿವೆ. ನಾವು Teamcity ಅನ್ನು ತೀರಾ ಇತ್ತೀಚಿನ ಉತ್ಪನ್ನವಾಗಿ ಆಯ್ಕೆ ಮಾಡಿಕೊಂಡಿದ್ದೇವೆ. ಆ ಸಮಯದಲ್ಲಿ, ನಾವು ಇನ್ನೂ ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಬಳಸಿರಲಿಲ್ಲ ಮತ್ತು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಕಾರ್ಯಗಳು ಮತ್ತು ಯೋಜನೆಗಳನ್ನು ನಿರೀಕ್ಷಿಸಿರಲಿಲ್ಲ.

ನಾವು ನಮ್ಮ ಸ್ವಂತ ವ್ಯವಸ್ಥೆಯ ಕಲ್ಪನೆಗೆ ಬರುತ್ತೇವೆ

ಟೀಮ್‌ಸಿಟಿಯ ಅನುಷ್ಠಾನವು ಹಸ್ತಚಾಲಿತ ಕೆಲಸದ ಭಾಗವನ್ನು ಮಾತ್ರ ತೆಗೆದುಹಾಕಲಾಗಿದೆ: ಪುಲ್ ವಿನಂತಿಗಳ ರಚನೆ, ಜಿರಾದಲ್ಲಿನ ಸ್ಥಿತಿಯ ಮೂಲಕ ಸಮಸ್ಯೆಗಳ ಪ್ರಚಾರ ಮತ್ತು ಬಿಡುಗಡೆಗಾಗಿ ಸಮಸ್ಯೆಗಳ ಆಯ್ಕೆಯಾಗಿದೆ. ಟೀಮ್‌ಸಿಟಿ ವ್ಯವಸ್ಥೆಯು ಇನ್ನು ಮುಂದೆ ಇದನ್ನು ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಮತ್ತಷ್ಟು ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಮಾರ್ಗವನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು ಅಗತ್ಯವಾಗಿತ್ತು. ಟೀಮ್‌ಸಿಟಿಯಲ್ಲಿ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಅಥವಾ ಥರ್ಡ್-ಪಾರ್ಟಿ ಆಟೊಮೇಷನ್ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ಬದಲಾಯಿಸಲು ನಾವು ಆಯ್ಕೆಗಳನ್ನು ಪರಿಗಣಿಸಿದ್ದೇವೆ. ಆದರೆ ಕೊನೆಯಲ್ಲಿ ನಾವು ಗರಿಷ್ಠ ನಮ್ಯತೆಯ ಅಗತ್ಯವಿದೆ ಎಂದು ನಿರ್ಧರಿಸಿದ್ದೇವೆ, ಅದು ನಮ್ಮ ಸ್ವಂತ ಪರಿಹಾರವನ್ನು ಮಾತ್ರ ಒದಗಿಸುತ್ತದೆ. ಇಂಟೆಗ್ರೊ ಎಂಬ ಆಂತರಿಕ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ವ್ಯವಸ್ಥೆಯ ಮೊದಲ ಆವೃತ್ತಿಯು ಹೇಗೆ ಕಾಣಿಸಿಕೊಂಡಿತು.

ಟೀಮ್‌ಸಿಟಿಯು ನಿರ್ಮಾಣ ಮತ್ತು ನಿಯೋಜನೆ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮಟ್ಟದಲ್ಲಿ ಯಾಂತ್ರೀಕರಣದೊಂದಿಗೆ ವ್ಯವಹರಿಸುತ್ತದೆ, ಆದರೆ ಇಂಟೆಗ್ರೋ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಗಳ ಉನ್ನತ ಮಟ್ಟದ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಿದೆ. ಬಿಟ್‌ಬಕೆಟ್‌ನಲ್ಲಿ ಸಂಯೋಜಿತ ಮೂಲ ಕೋಡ್‌ನ ಪ್ರಕ್ರಿಯೆಯೊಂದಿಗೆ ಜಿರಾದಲ್ಲಿನ ಸಮಸ್ಯೆಗಳೊಂದಿಗೆ ಕೆಲಸವನ್ನು ಸಂಯೋಜಿಸುವುದು ಅಗತ್ಯವಾಗಿತ್ತು. ಈ ಹಂತದಲ್ಲಿ, ಇಂಟೆಗ್ರೊ ವಿವಿಧ ರೀತಿಯ ಕಾರ್ಯಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ತನ್ನದೇ ಆದ ಕೆಲಸದ ಹರಿವನ್ನು ಹೊಂದಲು ಪ್ರಾರಂಭಿಸಿತು. 

ವ್ಯಾಪಾರ ಪ್ರಕ್ರಿಯೆಗಳಲ್ಲಿ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಹೆಚ್ಚಳದಿಂದಾಗಿ, ಟೀಮ್‌ಸಿಟಿಯಲ್ಲಿ ಯೋಜನೆಗಳು ಮತ್ತು ರನ್‌ಗಳ ಸಂಖ್ಯೆ ಹೆಚ್ಚಾಗಿದೆ. ಆದ್ದರಿಂದ ಹೊಸ ಸಮಸ್ಯೆ ಬಂದಿತು: ಒಂದು ಉಚಿತ ಟೀಮ್‌ಸಿಟಿ ನಿದರ್ಶನವು ಸಾಕಾಗಲಿಲ್ಲ (3 ಏಜೆಂಟ್‌ಗಳು ಮತ್ತು 100 ಪ್ರಾಜೆಕ್ಟ್‌ಗಳು), ನಾವು ಇನ್ನೊಂದು ನಿದರ್ಶನವನ್ನು ಸೇರಿಸಿದ್ದೇವೆ (3 ಹೆಚ್ಚಿನ ಏಜೆಂಟ್‌ಗಳು ಮತ್ತು 100 ಪ್ರಾಜೆಕ್ಟ್‌ಗಳು), ನಂತರ ಇನ್ನೊಂದು. ಪರಿಣಾಮವಾಗಿ, ನಾವು ಹಲವಾರು ಕ್ಲಸ್ಟರ್‌ಗಳ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅದನ್ನು ನಿರ್ವಹಿಸುವುದು ಕಷ್ಟಕರವಾಗಿತ್ತು:

4 ನೇ ನಿದರ್ಶನದ ಪ್ರಶ್ನೆಯು ಉದ್ಭವಿಸಿದಾಗ, ನಾವು ಈ ರೀತಿ ಬದುಕಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ನಾವು ಅರಿತುಕೊಂಡಿದ್ದೇವೆ, ಏಕೆಂದರೆ 4 ನಿದರ್ಶನಗಳನ್ನು ಬೆಂಬಲಿಸುವ ಒಟ್ಟು ವೆಚ್ಚಗಳು ಇನ್ನು ಮುಂದೆ ಯಾವುದೇ ಮಿತಿಯಲ್ಲಿಲ್ಲ. ಪಾವತಿಸಿದ ಟೀಮ್‌ಸಿಟಿಯನ್ನು ಖರೀದಿಸುವ ಅಥವಾ ಉಚಿತ ಜೆಂಕಿನ್ಸ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಬಗ್ಗೆ ಪ್ರಶ್ನೆ ಉದ್ಭವಿಸಿದೆ. ನಾವು ನಿದರ್ಶನಗಳು ಮತ್ತು ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಯೋಜನೆಗಳ ಮೇಲೆ ಲೆಕ್ಕಾಚಾರಗಳನ್ನು ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಜೆಂಕಿನ್ಸ್ನಲ್ಲಿ ವಾಸಿಸುತ್ತೇವೆ ಎಂದು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ಒಂದೆರಡು ವಾರಗಳ ನಂತರ, ನಾವು ಜೆಂಕಿನ್ಸ್‌ಗೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ ಮತ್ತು ಅನೇಕ ಟೀಮ್‌ಸಿಟಿ ನಿದರ್ಶನಗಳನ್ನು ನಿರ್ವಹಿಸುವುದರೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದ ಕೆಲವು ತಲೆನೋವನ್ನು ತೆಗೆದುಹಾಕಿದ್ದೇವೆ. ಆದ್ದರಿಂದ, ನಾವು ಇಂಟೆಗ್ರೊವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಮತ್ತು ಜೆಂಕಿನ್ಸ್ ಅನ್ನು ನಮಗಾಗಿ ಕಸ್ಟಮೈಸ್ ಮಾಡಲು ಕೇಂದ್ರೀಕರಿಸಲು ಸಾಧ್ಯವಾಯಿತು.

ಮೂಲಭೂತ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಬೆಳವಣಿಗೆಯೊಂದಿಗೆ (ಪುಲ್ ವಿನಂತಿಗಳ ಸ್ವಯಂಚಾಲಿತ ರಚನೆ, ಕೋಡ್ ಕವರೇಜ್ ಮತ್ತು ಇತರ ಚೆಕ್‌ಗಳ ಸಂಗ್ರಹಣೆ ಮತ್ತು ಪ್ರಕಟಣೆಯ ರೂಪದಲ್ಲಿ), ಸಾಧ್ಯವಾದಷ್ಟು ಕೈಯಿಂದ ಬಿಡುಗಡೆಗಳನ್ನು ತ್ಯಜಿಸಲು ಮತ್ತು ಈ ಕೆಲಸವನ್ನು ರೋಬೋಟ್‌ಗಳಿಗೆ ನೀಡುವ ಬಲವಾದ ಬಯಕೆಯಿದೆ. ಇದರ ಜೊತೆಯಲ್ಲಿ, ಕಂಪನಿಯು ಕಂಪನಿಯೊಳಗಿನ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳಿಗೆ ಚಲಿಸಲು ಪ್ರಾರಂಭಿಸಿತು, ಇದಕ್ಕೆ ಆಗಾಗ್ಗೆ ಬಿಡುಗಡೆಗಳು ಬೇಕಾಗುತ್ತವೆ ಮತ್ತು ಪರಸ್ಪರ ಪ್ರತ್ಯೇಕವಾಗಿ. ನಾವು ಕ್ರಮೇಣ ನಮ್ಮ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳ ಸ್ವಯಂಚಾಲಿತ ಬಿಡುಗಡೆಗಳಿಗೆ ಹೇಗೆ ಬಂದಿದ್ದೇವೆ (ಪ್ರಕ್ರಿಯೆಯ ಸಂಕೀರ್ಣತೆಯಿಂದಾಗಿ ನಾವು ಪ್ರಸ್ತುತ ಏಕಶಿಲೆಯನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಬಿಡುಗಡೆ ಮಾಡುತ್ತಿದ್ದೇವೆ). ಆದರೆ, ಸಾಮಾನ್ಯವಾಗಿ ಸಂಭವಿಸಿದಂತೆ, ಹೊಸ ಸಂಕೀರ್ಣತೆ ಹುಟ್ಟಿಕೊಂಡಿತು. 

ನಾವು ಪರೀಕ್ಷೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುತ್ತೇವೆ

ಬಿಡುಗಡೆಗಳ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಕಾರಣ, ಕೆಲವು ಪರೀಕ್ಷಾ ಹಂತಗಳನ್ನು ಬಿಟ್ಟುಬಿಡುವುದರಿಂದ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಗಳು ವೇಗಗೊಂಡಿವೆ. ಮತ್ತು ಇದು ಗುಣಮಟ್ಟದ ತಾತ್ಕಾಲಿಕ ನಷ್ಟಕ್ಕೆ ಕಾರಣವಾಯಿತು. ಇದು ಕ್ಷುಲ್ಲಕವೆಂದು ತೋರುತ್ತದೆ, ಆದರೆ ಬಿಡುಗಡೆಗಳ ವೇಗವರ್ಧನೆಯ ಜೊತೆಗೆ, ಉತ್ಪನ್ನ ಅಭಿವೃದ್ಧಿ ವಿಧಾನವನ್ನು ಬದಲಾಯಿಸುವುದು ಅಗತ್ಯವಾಗಿತ್ತು. ಬಿಡುಗಡೆಯಾದ ಕೋಡ್ ಮತ್ತು ಅದರಲ್ಲಿನ ದೋಷಗಳಿಗಾಗಿ ಡೆವಲಪರ್‌ನ ಪರೀಕ್ಷೆಯ ಯಾಂತ್ರೀಕೃತಗೊಂಡ, ವೈಯಕ್ತಿಕ ಜವಾಬ್ದಾರಿಯನ್ನು (ಇಲ್ಲಿ ನಾವು “ತಲೆಯಲ್ಲಿ ಆಲೋಚನೆಯನ್ನು ಸ್ವೀಕರಿಸುವ” ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ, ವಿತ್ತೀಯ ದಂಡಗಳಲ್ಲ) ಕುರಿತು ಯೋಚಿಸುವುದು ಅಗತ್ಯವಾಗಿತ್ತು, ಜೊತೆಗೆ ನಿರ್ಧಾರ ಸ್ವಯಂಚಾಲಿತ ನಿಯೋಜನೆಯ ಮೂಲಕ ಕಾರ್ಯವನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿ/ಬಿಡುಗಡೆ ಮಾಡಬೇಡಿ. 

ಗುಣಮಟ್ಟದ ಸಮಸ್ಯೆಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದು, ನಾವು ಎರಡು ಪ್ರಮುಖ ನಿರ್ಧಾರಗಳಿಗೆ ಬಂದಿದ್ದೇವೆ: ನಾವು ಕ್ಯಾನರಿ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ ಮತ್ತು ಅದರ ಹೆಚ್ಚುವರಿಗೆ ಸ್ವಯಂಚಾಲಿತ ಪ್ರತಿಕ್ರಿಯೆಯೊಂದಿಗೆ ದೋಷ ಹಿನ್ನೆಲೆಯ ಸ್ವಯಂಚಾಲಿತ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಪರಿಚಯಿಸಿದ್ದೇವೆ. ಮೊದಲ ಪರಿಹಾರವು ಕೋಡ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಉತ್ಪಾದನೆಗೆ ಬಿಡುಗಡೆ ಮಾಡುವ ಮೊದಲು ಸ್ಪಷ್ಟ ದೋಷಗಳನ್ನು ಕಂಡುಹಿಡಿಯಲು ಸಾಧ್ಯವಾಗಿಸಿತು, ಎರಡನೆಯದು ಉತ್ಪಾದನೆಯಲ್ಲಿನ ಸಮಸ್ಯೆಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವನ್ನು ಕಡಿಮೆಗೊಳಿಸಿತು. ತಪ್ಪುಗಳು, ಸಹಜವಾಗಿ, ಸಂಭವಿಸುತ್ತವೆ, ಆದರೆ ನಾವು ನಮ್ಮ ಹೆಚ್ಚಿನ ಸಮಯ ಮತ್ತು ಶ್ರಮವನ್ನು ಅವುಗಳನ್ನು ಸರಿಪಡಿಸಲು ಅಲ್ಲ, ಆದರೆ ಅವುಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಕಳೆಯುತ್ತೇವೆ. 

ಆಟೋಮೇಷನ್ ತಂಡ

ನಾವು ಪ್ರಸ್ತುತ 130 ಡೆವಲಪರ್‌ಗಳ ಸಿಬ್ಬಂದಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಮುಂದುವರಿಸುತ್ತೇವೆ ಬೆಳೆಯಿರಿ. ನಿರಂತರ ಏಕೀಕರಣ ಮತ್ತು ಕೋಡ್ ವಿತರಣೆಗಾಗಿ ತಂಡವು (ಇನ್ನು ಮುಂದೆ ನಿಯೋಜನೆ ಮತ್ತು ಏಕೀಕರಣ ಅಥವಾ DI ತಂಡ ಎಂದು ಉಲ್ಲೇಖಿಸಲಾಗುತ್ತದೆ) 7 ಜನರನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ ಮತ್ತು 2 ದಿಕ್ಕುಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ: ಇಂಟೆಗ್ರೊ ಆಟೊಮೇಷನ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಮತ್ತು DevOps ಅಭಿವೃದ್ಧಿ. 

DevOps CIAN ಸೈಟ್‌ನ Dev/Beta ಪರಿಸರಕ್ಕೆ ಜವಾಬ್ದಾರವಾಗಿದೆ, ಇಂಟೆಗ್ರೊ ಪರಿಸರ, ಡೆವಲಪರ್‌ಗಳಿಗೆ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸ್ಕೇಲಿಂಗ್ ಪರಿಸರಕ್ಕೆ ಹೊಸ ವಿಧಾನಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತದೆ. ಇಂಟೆಗ್ರೊ ಅಭಿವೃದ್ಧಿ ನಿರ್ದೇಶನವು ಇಂಟೆಗ್ರೊ ಸ್ವತಃ ಮತ್ತು ಸಂಬಂಧಿತ ಸೇವೆಗಳೊಂದಿಗೆ ವ್ಯವಹರಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ಜೆಂಕಿನ್ಸ್, ಜಿರಾ, ಸಂಗಮಕ್ಕಾಗಿ ಪ್ಲಗಿನ್‌ಗಳು ಮತ್ತು ಅಭಿವೃದ್ಧಿ ತಂಡಗಳಿಗೆ ಸಹಾಯಕ ಉಪಯುಕ್ತತೆಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತದೆ. 

DI ತಂಡವು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ತಂಡದೊಂದಿಗೆ ಸಹಯೋಗದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಇದು ವಾಸ್ತುಶಿಲ್ಪ, ಗ್ರಂಥಾಲಯಗಳು ಮತ್ತು ಅಭಿವೃದ್ಧಿ ವಿಧಾನಗಳನ್ನು ಆಂತರಿಕವಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, CIAN ನಲ್ಲಿನ ಯಾವುದೇ ಡೆವಲಪರ್ ಯಾಂತ್ರೀಕರಣಕ್ಕೆ ಕೊಡುಗೆ ನೀಡಬಹುದು, ಉದಾಹರಣೆಗೆ, ತಂಡದ ಅಗತ್ಯಗಳಿಗೆ ಸರಿಹೊಂದುವಂತೆ ಮೈಕ್ರೋ-ಆಟೊಮೇಷನ್ ಮಾಡಿ ಅಥವಾ ಯಾಂತ್ರೀಕೃತಗೊಂಡವನ್ನು ಹೇಗೆ ಉತ್ತಮಗೊಳಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ತಂಪಾದ ಕಲ್ಪನೆಯನ್ನು ಹಂಚಿಕೊಳ್ಳಿ.

CIAN ನಲ್ಲಿ ಆಟೋಮೇಷನ್‌ನ ಲೇಯರ್ ಕೇಕ್

ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಎಲ್ಲಾ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಹಲವಾರು ಪದರಗಳಾಗಿ ವಿಂಗಡಿಸಬಹುದು:

1. ಬಾಹ್ಯ ವ್ಯವಸ್ಥೆಗಳು (ಜಿರಾ, ಬಿಟ್ಬಕೆಟ್, ಇತ್ಯಾದಿ). ಅಭಿವೃದ್ಧಿ ತಂಡಗಳು ಅವರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ.
2. ಇಂಟೆಗ್ರೊ ವೇದಿಕೆ. ಹೆಚ್ಚಾಗಿ, ಡೆವಲಪರ್‌ಗಳು ಅದರೊಂದಿಗೆ ನೇರವಾಗಿ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ, ಆದರೆ ಇದು ಎಲ್ಲಾ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಚಾಲನೆಯಲ್ಲಿದೆ.
3. ವಿತರಣೆ, ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಮತ್ತು ಅನ್ವೇಷಣೆ ಸೇವೆಗಳು (ಉದಾಹರಣೆಗೆ, ಜೆಕ್ನಿನ್ಸ್, ಕಾನ್ಸುಲ್, ಅಲೆಮಾರಿ). ಅವರ ಸಹಾಯದಿಂದ, ನಾವು ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಕೋಡ್ ಅನ್ನು ನಿಯೋಜಿಸುತ್ತೇವೆ ಮತ್ತು ಸೇವೆಗಳು ಪರಸ್ಪರ ಕೆಲಸ ಮಾಡುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುತ್ತೇವೆ.
4. ಭೌತಿಕ ಪದರ (ಸರ್ವರ್‌ಗಳು, ಓಎಸ್, ಸಂಬಂಧಿತ ಸಾಫ್ಟ್‌ವೇರ್). ನಮ್ಮ ಕೋಡ್ ಈ ಮಟ್ಟದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಇದು ಭೌತಿಕ ಸರ್ವರ್ ಆಗಿರಬಹುದು ಅಥವಾ ವರ್ಚುವಲ್ ಆಗಿರಬಹುದು (LXC, KVM, ಡಾಕರ್).

ಈ ಪರಿಕಲ್ಪನೆಯ ಆಧಾರದ ಮೇಲೆ, ನಾವು DI ತಂಡದೊಳಗೆ ಜವಾಬ್ದಾರಿಯ ಕ್ಷೇತ್ರಗಳನ್ನು ವಿಭಜಿಸುತ್ತೇವೆ. ಮೊದಲ ಎರಡು ಹಂತಗಳು ಇಂಟೆಗ್ರೊ ಅಭಿವೃದ್ಧಿ ನಿರ್ದೇಶನದ ಜವಾಬ್ದಾರಿಯ ಪ್ರದೇಶದಲ್ಲಿವೆ ಮತ್ತು ಕೊನೆಯ ಎರಡು ಹಂತಗಳು ಈಗಾಗಲೇ DevOps ನ ಜವಾಬ್ದಾರಿಯ ಪ್ರದೇಶದಲ್ಲಿವೆ. ಈ ಪ್ರತ್ಯೇಕತೆಯು ಕಾರ್ಯಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಪರಸ್ಪರ ಕ್ರಿಯೆಗೆ ಅಡ್ಡಿಯಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ನಾವು ಪರಸ್ಪರ ಹತ್ತಿರವಾಗಿದ್ದೇವೆ ಮತ್ತು ಜ್ಞಾನ ಮತ್ತು ಅನುಭವವನ್ನು ನಿರಂತರವಾಗಿ ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ.

ಹಾಗೇ

ಇಂಟೆಗ್ರೊ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸೋಣ ಮತ್ತು ತಂತ್ರಜ್ಞಾನದ ಸ್ಟ್ಯಾಕ್‌ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸೋಣ:

• ಸೆಂಟೋಸ್ 7
• ಡಾಕರ್ + ಅಲೆಮಾರಿ + ಕಾನ್ಸುಲ್ + ವಾಲ್ಟ್
• ಜಾವಾ 11 (ಹಳೆಯ ಇಂಟಿಗ್ರೊ ಏಕಶಿಲೆಯು ಜಾವಾ 8 ನಲ್ಲಿ ಉಳಿಯುತ್ತದೆ)
• ಸ್ಪ್ರಿಂಗ್ ಬೂಟ್ 2.X + ಸ್ಪ್ರಿಂಗ್ ಕ್ಲೌಡ್ ಕಾನ್ಫಿಗ್
• PostgreSql 11
• ಮೊಲ ಎಂಕ್ಯೂ 
• ಅಪಾಚೆ ಇಗ್ನೈಟ್
• ಕ್ಯಾಮುಂಡಾ (ಎಂಬೆಡೆಡ್)
• ಗ್ರಾಫನಾ + ಗ್ರ್ಯಾಫೈಟ್ + ಪ್ರಮೀತಿಯಸ್ + ಜೇಗರ್ + ELK
• ವೆಬ್ UI: ರಿಯಾಕ್ಟ್ (CSR) + MobX
• SSO: ಕೀಕ್ಲೋಕ್

ಇಂಟೆಗ್ರೊದ ಆರಂಭಿಕ ಆವೃತ್ತಿಯ ಏಕಶಿಲೆಯ ರೂಪದಲ್ಲಿ ನಾವು ಪರಂಪರೆಯನ್ನು ಹೊಂದಿದ್ದರೂ, ಮೈಕ್ರೋಸರ್ವಿಸ್ ಅಭಿವೃದ್ಧಿಯ ತತ್ವಕ್ಕೆ ನಾವು ಬದ್ಧರಾಗಿದ್ದೇವೆ. ಪ್ರತಿಯೊಂದು ಮೈಕ್ರೋ ಸರ್ವಿಸ್ ತನ್ನದೇ ಆದ ಡಾಕರ್ ಕಂಟೇನರ್‌ನಲ್ಲಿ ಚಲಿಸುತ್ತದೆ ಮತ್ತು ಸೇವೆಗಳು HTTP ವಿನಂತಿಗಳು ಮತ್ತು RabbitMQ ಸಂದೇಶಗಳ ಮೂಲಕ ಪರಸ್ಪರ ಸಂವಹನ ನಡೆಸುತ್ತವೆ. ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳು ಕಾನ್ಸುಲ್ ಮೂಲಕ ಪರಸ್ಪರ ಹುಡುಕುತ್ತವೆ ಮತ್ತು ಅದಕ್ಕೆ ವಿನಂತಿಯನ್ನು ಮಾಡುತ್ತವೆ, SSO (ಕೀಕ್ಲೋಕ್, OAuth 2/OpenID ಕನೆಕ್ಟ್) ಮೂಲಕ ದೃಢೀಕರಣವನ್ನು ರವಾನಿಸುತ್ತವೆ.

ನಿಜ ಜೀವನದ ಉದಾಹರಣೆಯಾಗಿ, ಕೆಳಗಿನ ಹಂತಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಜೆಂಕಿನ್ಸ್ ಜೊತೆ ಸಂವಹನ ನಡೆಸುವುದನ್ನು ಪರಿಗಣಿಸಿ:

1. ವರ್ಕ್‌ಫ್ಲೋ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಮೈಕ್ರೊ ಸರ್ವಿಸ್ (ಇನ್ನು ಮುಂದೆ ಫ್ಲೋ ಮೈಕ್ರೋ ಸರ್ವಿಸ್ ಎಂದು ಉಲ್ಲೇಖಿಸಲಾಗುತ್ತದೆ) ಜೆಂಕಿನ್ಸ್‌ನಲ್ಲಿ ಬಿಲ್ಡ್ ಅನ್ನು ಚಲಾಯಿಸಲು ಬಯಸುತ್ತದೆ. ಇದನ್ನು ಮಾಡಲು, ಅವರು ಜೆಂಕಿನ್ಸ್‌ನೊಂದಿಗೆ ಏಕೀಕರಣಕ್ಕಾಗಿ ಮೈಕ್ರೊ ಸರ್ವಿಸ್‌ನ IP: PORT ಅನ್ನು ಕಂಡುಹಿಡಿಯಲು ಕಾನ್ಸುಲ್ ಅನ್ನು ಬಳಸುತ್ತಾರೆ (ಇನ್ನು ಮುಂದೆ ಜೆಂಕಿನ್ಸ್ ಮೈಕ್ರೋಸರ್ವಿಸ್ ಎಂದು ಉಲ್ಲೇಖಿಸಲಾಗುತ್ತದೆ) ಮತ್ತು ಜೆಂಕಿನ್ಸ್‌ನಲ್ಲಿ ನಿರ್ಮಾಣವನ್ನು ಪ್ರಾರಂಭಿಸಲು ಅಸಮಕಾಲಿಕ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ.
2. ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಿದ ನಂತರ, ಜೆಂಕಿನ್ಸ್ ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ಜಾಬ್ ಐಡಿಯನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ, ನಂತರ ಅದನ್ನು ಕೆಲಸದ ಫಲಿತಾಂಶವನ್ನು ಗುರುತಿಸಲು ಬಳಸಬಹುದು. ಅದೇ ಸಮಯದಲ್ಲಿ, ಇದು REST API ಕರೆ ಮೂಲಕ ಜೆಂಕಿನ್ಸ್‌ನಲ್ಲಿ ನಿರ್ಮಾಣವನ್ನು ಪ್ರಚೋದಿಸುತ್ತದೆ.
3. ಜೆಂಕಿನ್ಸ್ ನಿರ್ಮಾಣವನ್ನು ನಿರ್ವಹಿಸುತ್ತಾನೆ ಮತ್ತು ಪೂರ್ಣಗೊಂಡ ನಂತರ, ಮರಣದಂಡನೆಯ ಫಲಿತಾಂಶಗಳೊಂದಿಗೆ ವೆಬ್‌ಹೂಕ್ ಅನ್ನು ಜೆಂಕಿನ್ಸ್ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗೆ ಕಳುಹಿಸುತ್ತಾನೆ.
4. ಜೆಂಕಿನ್ಸ್ ಮೈಕ್ರೊ ಸರ್ವಿಸ್, ವೆಬ್‌ಹೂಕ್ ಅನ್ನು ಸ್ವೀಕರಿಸಿದ ನಂತರ, ವಿನಂತಿಯ ಪ್ರಕ್ರಿಯೆಯ ಪೂರ್ಣಗೊಂಡ ಬಗ್ಗೆ ಸಂದೇಶವನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು ಅದಕ್ಕೆ ಮರಣದಂಡನೆ ಫಲಿತಾಂಶಗಳನ್ನು ಲಗತ್ತಿಸುತ್ತದೆ. ರಚಿತವಾದ ಸಂದೇಶವನ್ನು RabbitMQ ಕ್ಯೂಗೆ ಕಳುಹಿಸಲಾಗಿದೆ.
5. RabbitMQ ಮೂಲಕ, ಪ್ರಕಟಿತ ಸಂದೇಶವು ಫ್ಲೋ ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಅನ್ನು ತಲುಪುತ್ತದೆ, ಇದು ವಿನಂತಿ ಮತ್ತು ಸ್ವೀಕರಿಸಿದ ಸಂದೇಶದಿಂದ ಜಾಬ್ ಐಡಿಯನ್ನು ಹೊಂದಿಸುವ ಮೂಲಕ ಅದರ ಕಾರ್ಯವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಫಲಿತಾಂಶದ ಬಗ್ಗೆ ಕಲಿಯುತ್ತದೆ.

ಈಗ ನಾವು ಸುಮಾರು 30 ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಇದನ್ನು ಹಲವಾರು ಗುಂಪುಗಳಾಗಿ ವಿಂಗಡಿಸಬಹುದು:

1. ಸಂರಚನಾ ನಿರ್ವಹಣೆ.
2. ಬಳಕೆದಾರರೊಂದಿಗೆ ಮಾಹಿತಿ ಮತ್ತು ಸಂವಹನ (ಮೆಸೆಂಜರ್‌ಗಳು, ಮೇಲ್).
3. ಮೂಲ ಕೋಡ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲಾಗುತ್ತಿದೆ.
4. ನಿಯೋಜನೆ ಸಾಧನಗಳೊಂದಿಗೆ ಏಕೀಕರಣ (ಜೆಂಕಿನ್ಸ್, ಅಲೆಮಾರಿ, ಕಾನ್ಸುಲ್, ಇತ್ಯಾದಿ).
5. ಮಾನಿಟರಿಂಗ್ (ಬಿಡುಗಡೆಗಳು, ದೋಷಗಳು, ಇತ್ಯಾದಿ).
6. ವೆಬ್ ಉಪಯುಕ್ತತೆಗಳು (ಪರೀಕ್ಷಾ ಪರಿಸರವನ್ನು ನಿರ್ವಹಿಸಲು UI, ಅಂಕಿಅಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಇತ್ಯಾದಿ).
7. ಕಾರ್ಯ ಟ್ರ್ಯಾಕರ್‌ಗಳು ಮತ್ತು ಅಂತಹುದೇ ವ್ಯವಸ್ಥೆಗಳೊಂದಿಗೆ ಏಕೀಕರಣ.
8. ವಿವಿಧ ಕಾರ್ಯಗಳಿಗಾಗಿ ವರ್ಕ್‌ಫ್ಲೋ ನಿರ್ವಹಣೆ.

ಕೆಲಸದ ಹರಿವಿನ ಕಾರ್ಯಗಳು

ಇಂಟೆಗ್ರೊ ಕಾರ್ಯ ಜೀವನಚಕ್ರಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಚಟುವಟಿಕೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುತ್ತದೆ. ಸರಳೀಕೃತ ಪರಿಭಾಷೆಯಲ್ಲಿ, ಕಾರ್ಯದ ಜೀವನ ಚಕ್ರವನ್ನು ಜಿರಾದಲ್ಲಿನ ಕಾರ್ಯದ ಕೆಲಸದ ಹರಿವು ಎಂದು ತಿಳಿಯಲಾಗುತ್ತದೆ. ನಮ್ಮ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಗಳು ಪ್ರಾಜೆಕ್ಟ್, ಕಾರ್ಯದ ಪ್ರಕಾರ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯದಲ್ಲಿ ಆಯ್ಕೆಮಾಡಿದ ಆಯ್ಕೆಗಳನ್ನು ಅವಲಂಬಿಸಿ ಹಲವಾರು ವರ್ಕ್‌ಫ್ಲೋ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಹೊಂದಿವೆ. 

ನಾವು ಹೆಚ್ಚಾಗಿ ಬಳಸುವ ಕೆಲಸದ ಹರಿವನ್ನು ನೋಡೋಣ:

ರೇಖಾಚಿತ್ರದಲ್ಲಿ, ಇಂಟೆಗ್ರೊದಿಂದ ಪರಿವರ್ತನೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಕರೆಯಲಾಗುತ್ತದೆ ಎಂದು ಗೇರ್ ಸೂಚಿಸುತ್ತದೆ, ಆದರೆ ಮಾನವ ಆಕೃತಿಯು ಪರಿವರ್ತನೆಯನ್ನು ವ್ಯಕ್ತಿಯಿಂದ ಹಸ್ತಚಾಲಿತವಾಗಿ ಕರೆಯಲಾಗುತ್ತದೆ ಎಂದು ಸೂಚಿಸುತ್ತದೆ. ಈ ಕೆಲಸದ ಹರಿವಿನಲ್ಲಿ ಕಾರ್ಯವು ತೆಗೆದುಕೊಳ್ಳಬಹುದಾದ ಹಲವಾರು ಮಾರ್ಗಗಳನ್ನು ನೋಡೋಣ.

ಕ್ಯಾನರಿ ಪರೀಕ್ಷೆಗಳಿಲ್ಲದೆ DEV+BETA ನಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ಹಸ್ತಚಾಲಿತ ಪರೀಕ್ಷೆ (ಸಾಮಾನ್ಯವಾಗಿ ನಾವು ಏಕಶಿಲೆಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವುದು ಹೀಗೆ):

ಇತರ ಪರಿವರ್ತನೆ ಸಂಯೋಜನೆಗಳು ಇರಬಹುದು. ಕೆಲವೊಮ್ಮೆ ಸಮಸ್ಯೆಯು ತೆಗೆದುಕೊಳ್ಳುವ ಮಾರ್ಗವನ್ನು ಜಿರಾದಲ್ಲಿನ ಆಯ್ಕೆಗಳ ಮೂಲಕ ಆಯ್ಕೆ ಮಾಡಬಹುದು.

ಕಾರ್ಯ ಚಲನೆ

"DEV ಪರೀಕ್ಷೆ + ಕ್ಯಾನರಿ ಪರೀಕ್ಷೆಗಳು" ಕೆಲಸದ ಹರಿವಿನ ಮೂಲಕ ಕಾರ್ಯವು ಚಲಿಸಿದಾಗ ನಿರ್ವಹಿಸುವ ಮುಖ್ಯ ಹಂತಗಳನ್ನು ನೋಡೋಣ:

1. ಡೆವಲಪರ್ ಅಥವಾ PM ಕಾರ್ಯವನ್ನು ರಚಿಸುತ್ತದೆ.

2. ಡೆವಲಪರ್ ಕೆಲಸವನ್ನು ಕೆಲಸ ಮಾಡಲು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಪೂರ್ಣಗೊಂಡ ನಂತರ, ಇದು IN REVEW ಸ್ಥಿತಿಗೆ ಬದಲಾಗುತ್ತದೆ.

3. ಜಿರಾ ವೆಬ್‌ಹೂಕ್ ಅನ್ನು ಜಿರಾ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗೆ ಕಳುಹಿಸುತ್ತಾನೆ (ಜಿರಾ ಜೊತೆ ಏಕೀಕರಣಕ್ಕೆ ಜವಾಬ್ದಾರನಾಗಿರುತ್ತಾನೆ).

4. ಜಿರಾ ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ಕೆಲಸದ ಹರಿವನ್ನು ಪ್ರಾರಂಭಿಸಲು ಫ್ಲೋ ಸೇವೆಗೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ (ಕೆಲಸವನ್ನು ನಿರ್ವಹಿಸುವ ಆಂತರಿಕ ಕೆಲಸದ ಹರಿವುಗಳಿಗೆ ಜವಾಬ್ದಾರನಾಗಿರುತ್ತಾನೆ).

5. ಫ್ಲೋ ಸೇವೆಯ ಒಳಗೆ:

• ವಿಮರ್ಶಕರನ್ನು ಕಾರ್ಯಕ್ಕೆ ನಿಯೋಜಿಸಲಾಗಿದೆ (ಬಳಕೆದಾರರ ಮೈಕ್ರೋ ಸರ್ವೀಸ್ + ಜಿರಾ ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ಬಗ್ಗೆ ಎಲ್ಲವನ್ನೂ ತಿಳಿದಿರುತ್ತದೆ).
• ಮೂಲ ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ಮೂಲಕ (ಇದು ರೆಪೊಸಿಟರಿಗಳು ಮತ್ತು ಶಾಖೆಗಳ ಬಗ್ಗೆ ತಿಳಿದಿದೆ, ಆದರೆ ಕೋಡ್‌ನೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ), ನಮ್ಮ ಸಂಚಿಕೆಯ ಶಾಖೆಯನ್ನು ಹೊಂದಿರುವ ರೆಪೊಸಿಟರಿಗಳಿಗಾಗಿ ಹುಡುಕಾಟವನ್ನು ಮಾಡಲಾಗಿದೆ (ಹುಡುಕಾಟವನ್ನು ಸರಳಗೊಳಿಸಲು, ಶಾಖೆಯ ಹೆಸರು ಸಮಸ್ಯೆಯೊಂದಿಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ ಜಿರಾದಲ್ಲಿ ಸಂಖ್ಯೆ). ಹೆಚ್ಚಾಗಿ, ಒಂದು ಕಾರ್ಯವು ಒಂದು ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಕೇವಲ ಒಂದು ಶಾಖೆಯನ್ನು ಹೊಂದಿರುತ್ತದೆ; ಇದು ನಿಯೋಜನೆ ಸರದಿಯ ನಿರ್ವಹಣೆಯನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ರೆಪೊಸಿಟರಿಗಳ ನಡುವಿನ ಸಂಪರ್ಕವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
• ಕಂಡುಬರುವ ಪ್ರತಿಯೊಂದು ಶಾಖೆಗೆ, ಈ ಕೆಳಗಿನ ಕ್ರಮಗಳ ಅನುಕ್ರಮವನ್ನು ನಡೆಸಲಾಗುತ್ತದೆ:

  i) ಮಾಸ್ಟರ್ ಶಾಖೆಯನ್ನು ನವೀಕರಿಸಲಾಗುತ್ತಿದೆ (ಕೋಡ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು Git ಮೈಕ್ರೋ ಸರ್ವಿಸ್).
  ii) ಡೆವಲಪರ್‌ನಿಂದ ಬದಲಾವಣೆಗಳಿಂದ ಶಾಖೆಯನ್ನು ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ (ಬಿಟ್‌ಬಕೆಟ್ ಮೈಕ್ರೋ ಸರ್ವಿಸ್).
  iii) ಈ ಶಾಖೆಗಾಗಿ ಪುಲ್ ವಿನಂತಿಯನ್ನು ರಚಿಸಲಾಗಿದೆ (ಬಿಟ್‌ಬಕೆಟ್ ಮೈಕ್ರೋ ಸರ್ವಿಸ್).
  iv) ಹೊಸ ಪುಲ್ ವಿನಂತಿಯ ಕುರಿತು ಸಂದೇಶವನ್ನು ಡೆವಲಪರ್ ಚಾಟ್‌ಗಳಿಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ (ಅಧಿಸೂಚನೆಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗೆ ಸೂಚಿಸಿ).
  v) DEV (ಜೆಂಕಿನ್ಸ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಜೆಂಕಿನ್ಸ್ ಮೈಕ್ರೋ ಸರ್ವಿಸ್) ನಲ್ಲಿ ಕಾರ್ಯಗಳನ್ನು ನಿರ್ಮಿಸಿ, ಪರೀಕ್ಷಿಸಿ ಮತ್ತು ನಿಯೋಜಿಸಲು ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ.
  vi) ಹಿಂದಿನ ಎಲ್ಲಾ ಹಂತಗಳನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಪೂರ್ಣಗೊಳಿಸಿದರೆ, ಇಂಟೆಗ್ರೋ ತನ್ನ ಅನುಮೋದನೆಯನ್ನು ಪುಲ್ ವಿನಂತಿಯಲ್ಲಿ (ಬಿಟ್‌ಬಕೆಟ್ ಮೈಕ್ರೋ ಸರ್ವಿಸ್) ಇರಿಸುತ್ತದೆ.

• ಗೊತ್ತುಪಡಿಸಿದ ವಿಮರ್ಶಕರಿಂದ ಪುಲ್ ವಿನಂತಿಯಲ್ಲಿ ಅನುಮೋದಿಸಲು ಇಂಟೆಗ್ರೋ ಕಾಯುತ್ತಿದೆ.
• ಎಲ್ಲಾ ಅಗತ್ಯ ಅನುಮೋದನೆಗಳನ್ನು ಸ್ವೀಕರಿಸಿದ ತಕ್ಷಣ (ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳು ಧನಾತ್ಮಕವಾಗಿ ಉತ್ತೀರ್ಣವಾಗಿವೆ), ಇಂಟೆಗ್ರೋ ಕೆಲಸವನ್ನು ಟೆಸ್ಟ್ ಆನ್ ದೇವ್ (ಜಿರಾ ಮೈಕ್ರೋಸರ್ವಿಸ್) ಸ್ಥಿತಿಗೆ ವರ್ಗಾಯಿಸುತ್ತದೆ.

6. ಪರೀಕ್ಷಕರು ಕಾರ್ಯವನ್ನು ಪರೀಕ್ಷಿಸುತ್ತಾರೆ. ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಲ್ಲದಿದ್ದರೆ, ಕಾರ್ಯವನ್ನು ನಿರ್ಮಿಸಲು ಸಿದ್ಧ ಸ್ಥಿತಿಗೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ.

7. ಇಂಟೆಗ್ರೊ ಕಾರ್ಯವು ಬಿಡುಗಡೆಗೆ ಸಿದ್ಧವಾಗಿದೆ ಎಂದು "ನೋಡುತ್ತದೆ" ಮತ್ತು ಕ್ಯಾನರಿ ಮೋಡ್ನಲ್ಲಿ ಅದರ ನಿಯೋಜನೆಯನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ (ಜೆಂಕಿನ್ಸ್ ಮೈಕ್ರೋಸರ್ವಿಸ್). ಬಿಡುಗಡೆಯ ಸಿದ್ಧತೆಯನ್ನು ನಿಯಮಗಳ ಗುಂಪಿನಿಂದ ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಕಾರ್ಯವು ಅಗತ್ಯವಿರುವ ಸ್ಥಿತಿಯಲ್ಲಿದೆ, ಇತರ ಕಾರ್ಯಗಳಲ್ಲಿ ಯಾವುದೇ ಲಾಕ್‌ಗಳಿಲ್ಲ, ಪ್ರಸ್ತುತ ಈ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ನ ಯಾವುದೇ ಸಕ್ರಿಯ ಅಪ್‌ಲೋಡ್‌ಗಳಿಲ್ಲ, ಇತ್ಯಾದಿ.

8. ಕಾರ್ಯವನ್ನು ಕ್ಯಾನರಿ ಸ್ಥಿತಿಗೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ (ಜಿರಾ ಮೈಕ್ರೋ ಸರ್ವಿಸ್).

9. ಜೆಂಕಿನ್ಸ್ ಕ್ಯಾನರಿ ಮೋಡ್‌ನಲ್ಲಿ ನೋಮಾಡ್ ಮೂಲಕ ನಿಯೋಜನೆ ಕಾರ್ಯವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ (ಸಾಮಾನ್ಯವಾಗಿ 1-3 ನಿದರ್ಶನಗಳು) ಮತ್ತು ನಿಯೋಜನೆಯ ಬಗ್ಗೆ ಬಿಡುಗಡೆ ಮಾನಿಟರಿಂಗ್ ಸೇವೆ (ಡಿಪ್ಲೋವಾಚ್ ಮೈಕ್ರೊ ಸರ್ವಿಸ್) ಗೆ ಸೂಚಿಸುತ್ತಾರೆ.

10. DeployWatch microservice ದೋಷದ ಹಿನ್ನೆಲೆಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ಅಗತ್ಯವಿದ್ದರೆ ಅದಕ್ಕೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ. ದೋಷದ ಹಿನ್ನೆಲೆ ಮೀರಿದ್ದರೆ (ಹಿನ್ನೆಲೆ ರೂಢಿಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಲೆಕ್ಕಹಾಕಲಾಗುತ್ತದೆ), ಡೆವಲಪರ್‌ಗಳಿಗೆ ಸೂಚನೆ ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ಮೂಲಕ ಸೂಚಿಸಲಾಗುತ್ತದೆ. 5 ನಿಮಿಷಗಳ ನಂತರ ಡೆವಲಪರ್ ಪ್ರತಿಕ್ರಿಯಿಸದಿದ್ದರೆ (ಹಿಂತಿರುಗಿ ಅಥವಾ ಉಳಿಯಿರಿ ಕ್ಲಿಕ್ ಮಾಡಿ), ನಂತರ ಕ್ಯಾನರಿ ನಿದರ್ಶನಗಳ ಸ್ವಯಂಚಾಲಿತ ರೋಲ್ಬ್ಯಾಕ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ. ಹಿನ್ನೆಲೆಯನ್ನು ಮೀರದಿದ್ದರೆ, ಡೆವಲಪರ್ ಕಾರ್ಯ ನಿಯೋಜನೆಯನ್ನು ಉತ್ಪಾದನೆಗೆ ಹಸ್ತಚಾಲಿತವಾಗಿ ಪ್ರಾರಂಭಿಸಬೇಕು (UI ನಲ್ಲಿ ಬಟನ್ ಕ್ಲಿಕ್ ಮಾಡುವ ಮೂಲಕ). 60 ನಿಮಿಷಗಳಲ್ಲಿ ಡೆವಲಪರ್ ಉತ್ಪಾದನೆಗೆ ನಿಯೋಜನೆಯನ್ನು ಪ್ರಾರಂಭಿಸದಿದ್ದರೆ, ಭದ್ರತಾ ಕಾರಣಗಳಿಗಾಗಿ ಕ್ಯಾನರಿ ನಿದರ್ಶನಗಳನ್ನು ಸಹ ಹಿಂತಿರುಗಿಸಲಾಗುತ್ತದೆ.

11. ಉತ್ಪಾದನೆಗೆ ನಿಯೋಜನೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿದ ನಂತರ:

• ಕಾರ್ಯವನ್ನು ಉತ್ಪಾದನಾ ಸ್ಥಿತಿಗೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ (ಜಿರಾ ಮೈಕ್ರೋ ಸರ್ವಿಸ್).
• ಜೆಂಕಿನ್ಸ್ ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ನಿಯೋಜನೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ನಿಯೋಜನೆಯ ಬಗ್ಗೆ ಡಿಪ್ಲೋವಾಚ್ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗೆ ತಿಳಿಸುತ್ತದೆ.
• DeployWatch ಮೈಕ್ರೋಸರ್ವಿಸ್ ಉತ್ಪಾದನೆಯಲ್ಲಿನ ಎಲ್ಲಾ ಕಂಟೈನರ್‌ಗಳನ್ನು ನವೀಕರಿಸಲಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ (ಎಲ್ಲವನ್ನೂ ನವೀಕರಿಸದ ಸಂದರ್ಭಗಳಿವೆ).
• Notify microservice ಮೂಲಕ, ನಿಯೋಜನೆಯ ಫಲಿತಾಂಶಗಳ ಕುರಿತು ಅಧಿಸೂಚನೆಯನ್ನು ಉತ್ಪಾದನೆಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ.

12. ತಪ್ಪಾದ ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ನಡವಳಿಕೆ ಪತ್ತೆಯಾದಲ್ಲಿ ಡೆವಲಪರ್‌ಗಳು ಉತ್ಪಾದನೆಯಿಂದ ಕಾರ್ಯವನ್ನು ಹಿಂತಿರುಗಿಸಲು ಪ್ರಾರಂಭಿಸಲು 30 ನಿಮಿಷಗಳನ್ನು ಹೊಂದಿರುತ್ತಾರೆ. ಈ ಸಮಯದ ನಂತರ, ಕಾರ್ಯವನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮಾಸ್ಟರ್ (Git ಮೈಕ್ರೋ ಸರ್ವಿಸ್) ಗೆ ವಿಲೀನಗೊಳಿಸಲಾಗುತ್ತದೆ.

13. ಮಾಸ್ಟರ್‌ನಲ್ಲಿ ಯಶಸ್ವಿ ವಿಲೀನದ ನಂತರ, ಕಾರ್ಯ ಸ್ಥಿತಿಯನ್ನು ಮುಚ್ಚಲಾಗಿದೆ (ಜಿರಾ ಮೈಕ್ರೋ ಸರ್ವಿಸ್) ಗೆ ಬದಲಾಯಿಸಲಾಗುತ್ತದೆ.

ರೇಖಾಚಿತ್ರವು ಸಂಪೂರ್ಣವಾಗಿ ವಿವರವಾದಂತೆ ನಟಿಸುವುದಿಲ್ಲ (ವಾಸ್ತವದಲ್ಲಿ ಇನ್ನೂ ಹೆಚ್ಚಿನ ಹಂತಗಳಿವೆ), ಆದರೆ ಪ್ರಕ್ರಿಯೆಗಳಲ್ಲಿ ಏಕೀಕರಣದ ಮಟ್ಟವನ್ನು ನಿರ್ಣಯಿಸಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ನಾವು ಈ ಯೋಜನೆಯನ್ನು ಆದರ್ಶವಾಗಿ ಪರಿಗಣಿಸುವುದಿಲ್ಲ ಮತ್ತು ಸ್ವಯಂಚಾಲಿತ ಬಿಡುಗಡೆ ಮತ್ತು ನಿಯೋಜನೆ ಬೆಂಬಲದ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಸುಧಾರಿಸುತ್ತಿದ್ದೇವೆ.

ಮುಂದೆ ಏನು

ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಅಭಿವೃದ್ಧಿಗಾಗಿ ನಾವು ದೊಡ್ಡ ಯೋಜನೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಉದಾಹರಣೆಗೆ, ಏಕಶಿಲೆಯ ಬಿಡುಗಡೆಯ ಸಮಯದಲ್ಲಿ ಹಸ್ತಚಾಲಿತ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದು, ಸ್ವಯಂಚಾಲಿತ ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಸುಧಾರಿಸುವುದು ಮತ್ತು ಡೆವಲಪರ್‌ಗಳೊಂದಿಗೆ ಸಂವಹನವನ್ನು ಸುಧಾರಿಸುವುದು.

ಆದರೆ ಸದ್ಯಕ್ಕೆ ಇಲ್ಲಿಗೆ ನಿಲ್ಲಿಸೋಣ. ಯಾಂತ್ರೀಕೃತಗೊಂಡ ವಿಮರ್ಶೆಯಲ್ಲಿ ನಾವು ಅನೇಕ ವಿಷಯಗಳನ್ನು ಮೇಲ್ನೋಟಕ್ಕೆ ಆವರಿಸಿದ್ದೇವೆ, ಕೆಲವನ್ನು ಸ್ಪರ್ಶಿಸಲಾಗಿಲ್ಲ, ಆದ್ದರಿಂದ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಲು ನಾವು ಸಂತೋಷಪಡುತ್ತೇವೆ. ವಿವರವಾಗಿ ಏನನ್ನು ಒಳಗೊಳ್ಳಬೇಕು ಎಂಬುದರ ಕುರಿತು ಸಲಹೆಗಳಿಗಾಗಿ ನಾವು ಕಾಯುತ್ತಿದ್ದೇವೆ, ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ ಬರೆಯಿರಿ.

ಮೂಲ: www.habr.com