ಇಂದು, ಹೆಚ್ಚಿನ ಸಾಫ್ಟ್‌ವೇರ್ ಉತ್ಪನ್ನಗಳನ್ನು ತಂಡಗಳಲ್ಲಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ. ಯಶಸ್ವಿ ತಂಡದ ಅಭಿವೃದ್ಧಿಯ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ಸರಳ ರೇಖಾಚಿತ್ರದ ರೂಪದಲ್ಲಿ ಪ್ರತಿನಿಧಿಸಬಹುದು.

ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ನೀವು ಬರೆದ ನಂತರ, ನೀವು ಅದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು:

1. Таетотает.
2. ಇದು ನಿಮ್ಮ ಸಹೋದ್ಯೋಗಿಗಳು ಬರೆದ ಕೋಡ್ ಸೇರಿದಂತೆ ಯಾವುದನ್ನೂ ಮುರಿಯುವುದಿಲ್ಲ.

ಎರಡೂ ಷರತ್ತುಗಳನ್ನು ಪೂರೈಸಿದರೆ, ನೀವು ಯಶಸ್ಸಿನ ಹಾದಿಯಲ್ಲಿದ್ದೀರಿ. ಈ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ಸುಲಭವಾಗಿ ಪರಿಶೀಲಿಸಲು ಮತ್ತು ಲಾಭದಾಯಕ ಮಾರ್ಗದಿಂದ ವಿಪಥಗೊಳ್ಳದಿರಲು, ನಾವು ನಿರಂತರ ಏಕೀಕರಣದೊಂದಿಗೆ ಬಂದಿದ್ದೇವೆ.

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

• ಆತ್ಮೀಯ ಜನರು. ಯಾವುದೇ ಪ್ರೋಗ್ರಾಮರ್‌ನ ಒಂದು ಗಂಟೆಯ ಕೆಲಸವು ಯಾವುದೇ ಸರ್ವರ್‌ನ ಒಂದು ಗಂಟೆಯ ಕೆಲಸಕ್ಕಿಂತ ಹೆಚ್ಚು ದುಬಾರಿಯಾಗಿದೆ.
• ಜನರು ತಪ್ಪುಗಳನ್ನು ಮಾಡುತ್ತಾರೆ. ಆದ್ದರಿಂದ, ಪರೀಕ್ಷೆಗಳನ್ನು ತಪ್ಪಾದ ಶಾಖೆಯಲ್ಲಿ ನಡೆಸಿದಾಗ ಅಥವಾ ಪರೀಕ್ಷಕರಿಗೆ ತಪ್ಪು ಬದ್ಧತೆಯನ್ನು ಸಂಕಲಿಸಿದಾಗ ಸಂದರ್ಭಗಳು ಉದ್ಭವಿಸಬಹುದು.
• ಜನರು ಸೋಮಾರಿಗಳು. ಕಾಲಕಾಲಕ್ಕೆ, ನಾನು ಕೆಲಸವನ್ನು ಮುಗಿಸಿದಾಗ, ಆಲೋಚನೆ ಉದ್ಭವಿಸುತ್ತದೆ: “ಪರಿಶೀಲಿಸಲು ಏನು ಇದೆ? ನಾನು ಎರಡು ಸಾಲುಗಳನ್ನು ಬರೆದಿದ್ದೇನೆ - ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ! ನಿಮ್ಮಲ್ಲಿ ಕೆಲವರಿಗೂ ಕೆಲವೊಮ್ಮೆ ಅಂತಹ ಆಲೋಚನೆಗಳು ಇರುತ್ತವೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಆದರೆ ನೀವು ಯಾವಾಗಲೂ ಪರಿಶೀಲಿಸಬೇಕು.

Avito ಮೊಬೈಲ್ ಅಭಿವೃದ್ಧಿ ತಂಡದಲ್ಲಿ ನಿರಂತರ ಏಕೀಕರಣವನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ, ಅವರು ದಿನಕ್ಕೆ 0 ರಿಂದ 450 ಬಿಲ್ಡ್‌ಗಳಿಗೆ ಹೇಗೆ ಹೋದರು ಮತ್ತು ಯಂತ್ರಗಳು ದಿನಕ್ಕೆ 200 ಗಂಟೆಗಳ ಕಾಲ ಜೋಡಿಸುತ್ತವೆ ಎಂದು ನಿಕೊಲಾಯ್ ನೆಸ್ಟೆರೊವ್ ಹೇಳುತ್ತಾರೆ (ನೆಸ್ಟೆರೋವ್) CI/CD Android ಅಪ್ಲಿಕೇಶನ್‌ನ ಎಲ್ಲಾ ವಿಕಸನೀಯ ಬದಲಾವಣೆಗಳಲ್ಲಿ ಭಾಗವಹಿಸುವವರು.

ಕಥೆಯು Android ಆಜ್ಞೆಯ ಉದಾಹರಣೆಯನ್ನು ಆಧರಿಸಿದೆ, ಆದರೆ ಹೆಚ್ಚಿನ ವಿಧಾನಗಳು iOS ನಲ್ಲಿಯೂ ಅನ್ವಯಿಸುತ್ತವೆ.

ಒಂದಾನೊಂದು ಕಾಲದಲ್ಲಿ, ಒಬ್ಬ ವ್ಯಕ್ತಿ Avito Android ತಂಡದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರು. ವ್ಯಾಖ್ಯಾನದ ಪ್ರಕಾರ, ನಿರಂತರ ಏಕೀಕರಣದಿಂದ ಅವನಿಗೆ ಏನೂ ಅಗತ್ಯವಿಲ್ಲ: ಏಕೀಕರಿಸಲು ಯಾರೂ ಇರಲಿಲ್ಲ.

ಆದರೆ ಅಪ್ಲಿಕೇಶನ್ ಬೆಳೆಯಿತು, ಹೆಚ್ಚು ಹೆಚ್ಚು ಹೊಸ ಕಾರ್ಯಗಳು ಕಾಣಿಸಿಕೊಂಡವು ಮತ್ತು ಅದಕ್ಕೆ ಅನುಗುಣವಾಗಿ ತಂಡವು ಬೆಳೆಯಿತು. ಕೆಲವು ಹಂತದಲ್ಲಿ, ಕೋಡ್ ಏಕೀಕರಣ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹೆಚ್ಚು ಔಪಚಾರಿಕವಾಗಿ ಸ್ಥಾಪಿಸುವ ಸಮಯ. Git ಹರಿವನ್ನು ಬಳಸಲು ನಿರ್ಧರಿಸಲಾಯಿತು.

Git ಹರಿವಿನ ಪರಿಕಲ್ಪನೆಯು ಚಿರಪರಿಚಿತವಾಗಿದೆ: ಒಂದು ಯೋಜನೆಯು ಒಂದು ಸಾಮಾನ್ಯ ಅಭಿವೃದ್ಧಿ ಶಾಖೆಯನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ಪ್ರತಿ ಹೊಸ ವೈಶಿಷ್ಟ್ಯಕ್ಕಾಗಿ, ಡೆವಲಪರ್‌ಗಳು ಪ್ರತ್ಯೇಕ ಶಾಖೆಯನ್ನು ಕತ್ತರಿಸಿ, ಅದಕ್ಕೆ ಬದ್ಧರಾಗಿ, ತಳ್ಳುತ್ತಾರೆ ಮತ್ತು ಅವರು ತಮ್ಮ ಕೋಡ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿ ಶಾಖೆಯಲ್ಲಿ ವಿಲೀನಗೊಳಿಸಲು ಬಯಸಿದಾಗ, ತೆರೆಯಿರಿ ವಿನಂತಿಯನ್ನು ಎಳೆಯಿರಿ. ಜ್ಞಾನವನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಮತ್ತು ವಿಧಾನಗಳನ್ನು ಚರ್ಚಿಸಲು, ನಾವು ಕೋಡ್ ವಿಮರ್ಶೆಯನ್ನು ಪರಿಚಯಿಸಿದ್ದೇವೆ, ಅಂದರೆ, ಸಹೋದ್ಯೋಗಿಗಳು ಪರಸ್ಪರರ ಕೋಡ್ ಅನ್ನು ಪರಿಶೀಲಿಸಬೇಕು ಮತ್ತು ದೃಢೀಕರಿಸಬೇಕು.

ಪರೀಕ್ಷಣೆ

ನಿಮ್ಮ ಕಣ್ಣುಗಳಿಂದ ಕೋಡ್ ಅನ್ನು ನೋಡುವುದು ತಂಪಾಗಿದೆ, ಆದರೆ ಸಾಕಾಗುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ಸ್ವಯಂಚಾಲಿತ ತಪಾಸಣೆಗಳನ್ನು ಪರಿಚಯಿಸಲಾಗುತ್ತಿದೆ.

• ಮೊದಲನೆಯದಾಗಿ, ನಾವು ಪರಿಶೀಲಿಸುತ್ತೇವೆ ARK ಅಸೆಂಬ್ಲಿ.
• ಬಹಳಷ್ಟು ಜುನಿಟ್ ಪರೀಕ್ಷೆಗಳು.
• ನಾವು ಕೋಡ್ ವ್ಯಾಪ್ತಿಯನ್ನು ಪರಿಗಣಿಸುತ್ತೇವೆ, ನಾವು ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುತ್ತಿರುವುದರಿಂದ.

ಈ ತಪಾಸಣೆಗಳನ್ನು ಹೇಗೆ ನಡೆಸಬೇಕು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, Avito ನಲ್ಲಿನ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನೋಡೋಣ.

ಇದನ್ನು ಕ್ರಮಬದ್ಧವಾಗಿ ಈ ರೀತಿ ಪ್ರತಿನಿಧಿಸಬಹುದು:

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

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

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

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

ಪರಿಣಾಮವಾಗಿ, ನಾವು ಈ ಕೆಳಗಿನ ಕಾರ್ಯತಂತ್ರವನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ: ನಾವು ರಾತ್ರಿಯಲ್ಲಿ ಗರಿಷ್ಠ ಸಂಭವನೀಯ ಚೆಕ್‌ಗಳನ್ನು ನಡೆಸುತ್ತೇವೆ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಅತ್ಯಂತ ನಿರ್ಣಾಯಕವಾದವುಗಳನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ ಮತ್ತು ಮುಖ್ಯವಾಗಿ, ಪುಲ್ ವಿನಂತಿಯಲ್ಲಿ ವೇಗವಾದವುಗಳನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ. ಆದರೆ ನಾವು ಅಲ್ಲಿ ನಿಲ್ಲುವುದಿಲ್ಲ - ಸಮಾನಾಂತರವಾಗಿ, ವಿನಂತಿಯ ಪರಿಶೀಲನೆಗಳನ್ನು ಎಳೆಯಲು ರಾತ್ರಿ ಮೋಡ್‌ನಿಂದ ಅವುಗಳನ್ನು ವರ್ಗಾಯಿಸಲು ನಾವು ಚೆಕ್‌ಗಳ ವೇಗವನ್ನು ಉತ್ತಮಗೊಳಿಸುತ್ತೇವೆ.

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

ಮೂಲಭೂತ CI ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಹೊಂದಿಸಲು ನಮಗೆ ಎರಡು ದಿನಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು (ಇನ್ನು ಮುಂದೆ ಸಮಯದ ಅಂದಾಜು ಅಂದಾಜು, ಪ್ರಮಾಣಕ್ಕೆ ಅಗತ್ಯವಿದೆ).

ಅದರ ನಂತರ, ನಾವು ಮತ್ತಷ್ಟು ಯೋಚಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ - ನಾವು ಸರಿಯಾಗಿ ಪರಿಶೀಲಿಸುತ್ತಿದ್ದೇವೆಯೇ? ಪುಲ್ ವಿನಂತಿಗಳ ಮೇಲೆ ನಾವು ಬಿಲ್ಡ್‌ಗಳನ್ನು ಸರಿಯಾಗಿ ನಡೆಸುತ್ತಿದ್ದೇವೆಯೇ?

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

ಇದನ್ನು ಮಾಡಲು, ನಾವು ಸರಳವಾದ ಬ್ಯಾಷ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಬರೆದಿದ್ದೇವೆ 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 ಗಳನ್ನು ತೆರೆಯುತ್ತೇವೆ: ಎರಡು ನಿರ್ಮಾಣಗಳು, ಎರಡು ರನ್ಗಳ ಚೆಕ್ಗಳು. ಮೊದಲ PR ಅನ್ನು ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ವಿಲೀನಗೊಳಿಸಿದ ನಂತರ, ಎರಡನೆಯದನ್ನು ಮರುನಿರ್ಮಾಣ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಒಟ್ಟಾರೆಯಾಗಿ, ಎರಡು PR ಗಳಿಗೆ ಮೂರು ರನ್ ಚೆಕ್‌ಗಳ ಅಗತ್ಯವಿದೆ: 2 + 1 = 3.

ತಾತ್ವಿಕವಾಗಿ, ಇದು ಉತ್ತಮವಾಗಿದೆ. ಆದರೆ ನಾವು ಅಂಕಿಅಂಶಗಳನ್ನು ನೋಡಿದ್ದೇವೆ ಮತ್ತು ನಮ್ಮ ತಂಡದಲ್ಲಿ ವಿಶಿಷ್ಟವಾದ ಪರಿಸ್ಥಿತಿಯು 10 ತೆರೆದ PR ಗಳು, ಮತ್ತು ನಂತರ ಚೆಕ್‌ಗಳ ಸಂಖ್ಯೆಯು ಪ್ರಗತಿಯ ಮೊತ್ತವಾಗಿದೆ: 10 + 9 +... + 1 = 55. ಅಂದರೆ, 10 ಅನ್ನು ಸ್ವೀಕರಿಸಲು PRಗಳು, ನೀವು 55 ಬಾರಿ ಮರುನಿರ್ಮಾಣ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಮತ್ತು ಇದು ಆದರ್ಶ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿದೆ, ಎಲ್ಲಾ ಚೆಕ್‌ಗಳು ಮೊದಲ ಬಾರಿಗೆ ಹಾದುಹೋದಾಗ, ಈ ಡಜನ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತಿರುವಾಗ ಯಾರೂ ಹೆಚ್ಚುವರಿ ಪುಲ್ ವಿನಂತಿಯನ್ನು ತೆರೆಯದಿದ್ದಾಗ.

"ವಿಲೀನ" ಬಟನ್ ಅನ್ನು ಮೊದಲು ಕ್ಲಿಕ್ ಮಾಡುವ ಡೆವಲಪರ್ ಎಂದು ನೀವೇ ಊಹಿಸಿಕೊಳ್ಳಿ, ಏಕೆಂದರೆ ನೆರೆಹೊರೆಯವರು ಇದನ್ನು ಮಾಡಿದರೆ, ಎಲ್ಲಾ ನಿರ್ಮಾಣಗಳು ಮತ್ತೆ ಹಾದುಹೋಗುವವರೆಗೆ ನೀವು ಕಾಯಬೇಕಾಗುತ್ತದೆ... ಇಲ್ಲ, ಅದು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ , ಇದು ಅಭಿವೃದ್ಧಿಯನ್ನು ಗಂಭೀರವಾಗಿ ನಿಧಾನಗೊಳಿಸುತ್ತದೆ.

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

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

ಈ ಪ್ಲಗಿನ್ ಪುಲ್ ವಿನಂತಿಯನ್ನು ವಿಲೀನಗೊಳಿಸುವ ಕಾರ್ಯವಿಧಾನವನ್ನು ಅತಿಕ್ರಮಿಸುತ್ತದೆ. ಪ್ರಾರಂಭವು ಪ್ರಮಾಣಿತವಾಗಿದೆ: PR ತೆರೆಯುತ್ತದೆ, ಎಲ್ಲಾ ಅಸೆಂಬ್ಲಿಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ, ಕೋಡ್ ಪರಿಶೀಲನೆ ಪೂರ್ಣಗೊಂಡಿದೆ. ಆದರೆ ಕೋಡ್ ಪರಿಶೀಲನೆ ಪೂರ್ಣಗೊಂಡ ನಂತರ ಮತ್ತು ಡೆವಲಪರ್ "ವಿಲೀನಗೊಳಿಸು" ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡಲು ನಿರ್ಧರಿಸಿದ ನಂತರ, ಪ್ಲಗಿನ್ ಚೆಕ್‌ಗಳನ್ನು ಚಲಾಯಿಸಿದ ಸ್ಥಿತಿಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತದೆ. ಬಿಲ್ಡ್‌ಗಳ ನಂತರ ಅಭಿವೃದ್ಧಿಯನ್ನು ನವೀಕರಿಸಿದ್ದರೆ, ಅಂತಹ ಪುಲ್ ವಿನಂತಿಯನ್ನು ಮುಖ್ಯ ಶಾಖೆಯಲ್ಲಿ ವಿಲೀನಗೊಳಿಸಲು ಪ್ಲಗಿನ್ ಅನುಮತಿಸುವುದಿಲ್ಲ. ಇದು ತುಲನಾತ್ಮಕವಾಗಿ ಇತ್ತೀಚಿನ ಅಭಿವೃದ್ಧಿಯ ನಿರ್ಮಾಣಗಳನ್ನು ಸರಳವಾಗಿ ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ.

ಸಂಘರ್ಷದ ಬದಲಾವಣೆಗಳೊಂದಿಗೆ ನಮ್ಮ ಉದಾಹರಣೆಯಲ್ಲಿ, ಸಂಕಲನ ದೋಷದಿಂದಾಗಿ ಅಂತಹ ನಿರ್ಮಾಣಗಳು ವಿಫಲಗೊಳ್ಳುತ್ತವೆ. ಅಂತೆಯೇ, ವೈಶಿಷ್ಟ್ಯ B ಯ ಡೆವಲಪರ್ ಕೋಡ್ ಅನ್ನು ಸರಿಪಡಿಸಬೇಕು, ಚೆಕ್‌ಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸಬೇಕು, ನಂತರ ಪ್ಲಗಿನ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪುಲ್ ವಿನಂತಿಯನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ.

ಈ ಪ್ಲಗಿನ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮೊದಲು, ನಾವು ಪ್ರತಿ ಪುಲ್ ವಿನಂತಿಗೆ ಸರಾಸರಿ 2,7 ವಿಮರ್ಶೆ ರನ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಪ್ಲಗಿನ್‌ನೊಂದಿಗೆ 3,6 ಉಡಾವಣೆಗಳು ಇದ್ದವು. ಇದು ನಮಗೆ ಹೊಂದಿಕೆಯಾಯಿತು.

ಈ ಪ್ಲಗಿನ್ ನ್ಯೂನತೆಯನ್ನು ಹೊಂದಿದೆ ಎಂದು ಗಮನಿಸಬೇಕಾದ ಅಂಶವಾಗಿದೆ: ಇದು ಒಮ್ಮೆ ಮಾತ್ರ ನಿರ್ಮಾಣವನ್ನು ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಅಂದರೆ, ಸಂಘರ್ಷದ ಬದಲಾವಣೆಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಸಾಧ್ಯವಾಗುವ ಸಣ್ಣ ವಿಂಡೋ ಇನ್ನೂ ಇದೆ. ಆದರೆ ಇದರ ಸಂಭವನೀಯತೆ ಕಡಿಮೆ, ಮತ್ತು ನಾವು ಪ್ರಾರಂಭಗಳ ಸಂಖ್ಯೆ ಮತ್ತು ವೈಫಲ್ಯದ ಸಾಧ್ಯತೆಯ ನಡುವೆ ಈ ವ್ಯಾಪಾರವನ್ನು ಮಾಡಿದ್ದೇವೆ. ಎರಡು ವರ್ಷಗಳಲ್ಲಿ ಅದು ಒಮ್ಮೆ ಮಾತ್ರ ಹಾರಿಸಿತು, ಆದ್ದರಿಂದ ಅದು ಬಹುಶಃ ವ್ಯರ್ಥವಾಗಲಿಲ್ಲ.

ಬಿಟ್‌ಬಕೆಟ್ ಪ್ಲಗಿನ್‌ನ ಮೊದಲ ಆವೃತ್ತಿಯನ್ನು ಬರೆಯಲು ನಮಗೆ ಎರಡು ವಾರಗಳು ಬೇಕಾಯಿತು.

ಹೊಸ ಚೆಕ್‌ಗಳು

ಏತನ್ಮಧ್ಯೆ, ನಮ್ಮ ತಂಡವು ಬೆಳೆಯುತ್ತಲೇ ಇತ್ತು. ಹೊಸ ಚೆಕ್‌ಗಳನ್ನು ಸೇರಿಸಲಾಗಿದೆ.

ನಾವು ಯೋಚಿಸಿದ್ದೇವೆ: ತಡೆಯಬಹುದಾದರೆ ತಪ್ಪುಗಳನ್ನು ಏಕೆ ಮಾಡಬೇಕು? ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ಅವರು ಜಾರಿಗೆ ತಂದರು ಸ್ಥಿರ ಕೋಡ್ ವಿಶ್ಲೇಷಣೆ. ನಾವು ಲಿಂಟ್‌ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ, ಇದನ್ನು Android SDK ನಲ್ಲಿ ಸೇರಿಸಲಾಗಿದೆ. ಆದರೆ ಆ ಸಮಯದಲ್ಲಿ ಅವರು ಕೋಟ್ಲಿನ್ ಕೋಡ್‌ನೊಂದಿಗೆ ಹೇಗೆ ಕೆಲಸ ಮಾಡಬೇಕೆಂದು ತಿಳಿದಿರಲಿಲ್ಲ, ಮತ್ತು ನಾವು ಈಗಾಗಲೇ ಕೋಟ್ಲಿನ್‌ನಲ್ಲಿ ಬರೆದ ಅಪ್ಲಿಕೇಶನ್‌ನ 75% ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಆದ್ದರಿಂದ, ಅಂತರ್ನಿರ್ಮಿತವಾದವುಗಳನ್ನು ಲಿಂಟ್ಗೆ ಸೇರಿಸಲಾಯಿತು Android ಸ್ಟುಡಿಯೋ ಪರಿಶೀಲನೆಗಳು.

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

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

ಆದರೆ ಸಾಧನ ಪರೀಕ್ಷೆಗಳು ಮತ್ತು ಸ್ಕ್ರೀನ್‌ಶಾಟ್ ಪರೀಕ್ಷೆಗಳನ್ನು ಸಾಧನಗಳಲ್ಲಿ ರನ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ: ಎಮ್ಯುಲೇಟರ್‌ಗಳಲ್ಲಿ ಅಥವಾ ನೈಜ ಸಾಧನಗಳಲ್ಲಿ. ಬಹಳಷ್ಟು ಪರೀಕ್ಷೆಗಳು ಇವೆ ಮತ್ತು ಅವುಗಳು ಆಗಾಗ್ಗೆ ನಡೆಸಲ್ಪಡುತ್ತವೆ ಎಂದು ಪರಿಗಣಿಸಿ, ಇಡೀ ಫಾರ್ಮ್ ಅಗತ್ಯವಿದೆ. ನಿಮ್ಮ ಸ್ವಂತ ಫಾರ್ಮ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವುದು ತುಂಬಾ ಶ್ರಮದಾಯಕವಾಗಿದೆ, ಆದ್ದರಿಂದ ನಾವು ಸಿದ್ಧ ಆಯ್ಕೆಯನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ - Firebase Test Lab.

ಫೈರ್‌ಬೇಸ್ ಟೆಸ್ಟ್ ಲ್ಯಾಬ್

Firebase Google ಉತ್ಪನ್ನವಾಗಿರುವುದರಿಂದ ಇದನ್ನು ಆಯ್ಕೆ ಮಾಡಲಾಗಿದೆ, ಅಂದರೆ ಅದು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿರಬೇಕು ಮತ್ತು ಎಂದಿಗೂ ಸಾಯುವ ಸಾಧ್ಯತೆಯಿಲ್ಲ. ಬೆಲೆಗಳು ಸಮಂಜಸವಾಗಿದೆ: ನಿಜವಾದ ಸಾಧನದ ಕಾರ್ಯಾಚರಣೆಯ ಗಂಟೆಗೆ $ 5, ಎಮ್ಯುಲೇಟರ್ ಕಾರ್ಯಾಚರಣೆಯ ಗಂಟೆಗೆ 1 $.

Firebase Test Lab ಅನ್ನು ನಮ್ಮ CI ಗೆ ಅಳವಡಿಸಲು ಇದು ಸರಿಸುಮಾರು ಮೂರು ವಾರಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು.

ಆದರೆ ತಂಡವು ಬೆಳೆಯುತ್ತಲೇ ಇತ್ತು, ಮತ್ತು ಫೈರ್‌ಬೇಸ್, ದುರದೃಷ್ಟವಶಾತ್, ನಮ್ಮನ್ನು ನಿರಾಸೆಗೊಳಿಸಿತು. ಆ ಸಮಯದಲ್ಲಿ, ಅವರು ಯಾವುದೇ SLA ಹೊಂದಿರಲಿಲ್ಲ. ಕೆಲವೊಮ್ಮೆ ಫೈರ್‌ಬೇಸ್ ನಮಗೆ ಅಗತ್ಯವಿರುವ ಸಂಖ್ಯೆಯ ಸಾಧನಗಳು ಪರೀಕ್ಷೆಗಳಿಗೆ ಮುಕ್ತವಾಗುವವರೆಗೆ ಕಾಯುವಂತೆ ಮಾಡಿತು ಮತ್ತು ನಾವು ಬಯಸಿದಂತೆ ಅವುಗಳನ್ನು ತಕ್ಷಣವೇ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸಲಿಲ್ಲ. ಸಾಲಿನಲ್ಲಿ ಕಾಯಲು ಅರ್ಧ ಘಂಟೆಯವರೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಇದು ಬಹಳ ಸಮಯ. ಪ್ರತಿ PR ನಲ್ಲಿ ಇನ್‌ಸ್ಟ್ರುಮೆಂಟೇಶನ್ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಲಾಯಿತು, ವಿಳಂಬಗಳು ನಿಜವಾಗಿಯೂ ಅಭಿವೃದ್ಧಿಯನ್ನು ನಿಧಾನಗೊಳಿಸಿದವು ಮತ್ತು ನಂತರ ಮಾಸಿಕ ಬಿಲ್ ಒಂದು ಸುತ್ತಿನ ಮೊತ್ತದೊಂದಿಗೆ ಬಂದಿತು. ಸಾಮಾನ್ಯವಾಗಿ, ತಂಡವು ಸಾಕಷ್ಟು ಬೆಳೆದಿರುವುದರಿಂದ ಫೈರ್‌ಬೇಸ್ ಅನ್ನು ತ್ಯಜಿಸಲು ಮತ್ತು ಮನೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ನಿರ್ಧರಿಸಲಾಯಿತು.

ಡಾಕರ್ + ಪೈಥಾನ್ + ಬ್ಯಾಷ್

ನಾವು ಡಾಕರ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ, ಅದರಲ್ಲಿ ಎಮ್ಯುಲೇಟರ್‌ಗಳನ್ನು ತುಂಬಿಸಿ, ಪೈಥಾನ್‌ನಲ್ಲಿ ಸರಳವಾದ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಬರೆದಿದ್ದೇವೆ, ಅದು ಸರಿಯಾದ ಸಮಯದಲ್ಲಿ ಸರಿಯಾದ ಆವೃತ್ತಿಯಲ್ಲಿ ಅಗತ್ಯವಿರುವ ಸಂಖ್ಯೆಯ ಎಮ್ಯುಲೇಟರ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ಅಗತ್ಯವಿದ್ದಾಗ ಅವುಗಳನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. ಮತ್ತು, ಸಹಜವಾಗಿ, ಒಂದೆರಡು ಬ್ಯಾಷ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು - ಅವುಗಳಿಲ್ಲದೆ ನಾವು ಎಲ್ಲಿದ್ದೇವೆ?

ನಮ್ಮದೇ ಆದ ಪರೀಕ್ಷಾ ವಾತಾವರಣವನ್ನು ಸೃಷ್ಟಿಸಲು ಇದು ಐದು ವಾರಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು.

ಪರಿಣಾಮವಾಗಿ, ಪ್ರತಿ ಪುಲ್ ವಿನಂತಿಗೆ ವ್ಯಾಪಕವಾದ ವಿಲೀನ-ತಡೆಗಟ್ಟುವ ಚೆಕ್‌ಗಳ ಪಟ್ಟಿ ಇತ್ತು:

• ARK ಅಸೆಂಬ್ಲಿ;
• ಜೂನಿಟ್ ಪರೀಕ್ಷೆಗಳು;
• ಲಿಂಟ್;
• Android ಸ್ಟುಡಿಯೋ ತಪಾಸಣೆ;
• ವಾದ್ಯ ಪರೀಕ್ಷೆಗಳು;
• ಸ್ಕ್ರೀನ್‌ಶಾಟ್ ಪರೀಕ್ಷೆಗಳು.

ಇದು ಅನೇಕ ಸಂಭವನೀಯ ಸ್ಥಗಿತಗಳನ್ನು ತಡೆಯಿತು. ತಾಂತ್ರಿಕವಾಗಿ ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡಿದೆ, ಆದರೆ ಫಲಿತಾಂಶಗಳಿಗಾಗಿ ಕಾಯುವಿಕೆ ತುಂಬಾ ಉದ್ದವಾಗಿದೆ ಎಂದು ಅಭಿವರ್ಧಕರು ದೂರಿದ್ದಾರೆ.

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

ಸಹಜವಾಗಿ, ನಮ್ಮ ಎಲ್ಲಾ ನಿರ್ಮಾಣಗಳನ್ನು ವೇಗಗೊಳಿಸಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.

ವೇಗವನ್ನು ಹೆಚ್ಚಿಸೋಣ

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

ತುಂಬಾ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುವ ಚೆಕ್‌ಗಳನ್ನು ತೆಗೆದುಹಾಕಲಾಗುತ್ತಿದೆ

ನಮ್ಮ ನಿರಂತರ ಏಕೀಕರಣವು ಈ ರೀತಿಯ ದೋಷಗಳು ಮತ್ತು ಸಮಸ್ಯೆಗಳನ್ನು ಹಿಡಿಯಬಹುದು.

• ಹೋಗುತ್ತಿಲ್ಲ. ಸಂಘರ್ಷದ ಬದಲಾವಣೆಗಳಿಂದಾಗಿ ಏನನ್ನಾದರೂ ನಿರ್ಮಿಸದಿದ್ದಾಗ CI ಸಂಕಲನ ದೋಷವನ್ನು ಹಿಡಿಯಬಹುದು. ನಾನು ಈಗಾಗಲೇ ಹೇಳಿದಂತೆ, ನಂತರ ಯಾರೂ ಏನನ್ನೂ ಜೋಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಅಭಿವೃದ್ಧಿ ನಿಲ್ಲುತ್ತದೆ, ಮತ್ತು ಎಲ್ಲರೂ ನರಗಳಾಗುತ್ತಾರೆ.
• ವರ್ತನೆಯಲ್ಲಿ ದೋಷ. ಉದಾಹರಣೆಗೆ, ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿರ್ಮಿಸಿದಾಗ, ಆದರೆ ನೀವು ಗುಂಡಿಯನ್ನು ಒತ್ತಿದಾಗ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತದೆ ಅಥವಾ ಬಟನ್ ಅನ್ನು ಒತ್ತದೇ ಇರುವಾಗ. ಇದು ಕೆಟ್ಟದು ಏಕೆಂದರೆ ಅಂತಹ ದೋಷವು ಬಳಕೆದಾರರನ್ನು ತಲುಪಬಹುದು.
• ಲೇಔಟ್‌ನಲ್ಲಿ ದೋಷವಿದೆ. ಉದಾಹರಣೆಗೆ, ಒಂದು ಬಟನ್ ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡಲಾಗಿದೆ, ಆದರೆ 10 ಪಿಕ್ಸೆಲ್‌ಗಳನ್ನು ಎಡಕ್ಕೆ ಸರಿಸಲಾಗಿದೆ.
• ತಾಂತ್ರಿಕ ಸಾಲದಲ್ಲಿ ಹೆಚ್ಚಳ.

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

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

ಪರಿಣಾಮವಾಗಿ, ನಾವು ಉಳಿದಿದ್ದೇವೆ:

• ARK ಅಸೆಂಬ್ಲಿ;
• ಜೂನಿಟ್ ಪರೀಕ್ಷೆಗಳು;
• ವಾದ್ಯ ಪರೀಕ್ಷೆಗಳು.

ಗ್ರೇಡಲ್ ರಿಮೋಟ್ ಕ್ಯಾಶ್

ಭಾರೀ ತಪಾಸಣೆ ಇಲ್ಲದೆ, ಎಲ್ಲವೂ ಉತ್ತಮವಾಯಿತು. ಆದರೆ ಪರಿಪೂರ್ಣತೆಗೆ ಮಿತಿಯಿಲ್ಲ!

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

ಗ್ರೆಡಲ್ ರಿಮೋಟ್ ಕ್ಯಾಶ್ ಎನ್ನುವುದು ಪ್ರತ್ಯೇಕ ಮಾಡ್ಯೂಲ್‌ಗಳಲ್ಲಿ ವೈಯಕ್ತಿಕ ಕಾರ್ಯಗಳಿಗಾಗಿ ಕಲಾಕೃತಿಗಳನ್ನು ಸಂಗ್ರಹಿಸಬಹುದಾದ ಸೇವೆಯಾಗಿದೆ. Gradle, ವಾಸ್ತವವಾಗಿ ಕೋಡ್ ಅನ್ನು ಕಂಪೈಲ್ ಮಾಡುವ ಬದಲು, ರಿಮೋಟ್ ಸಂಗ್ರಹವನ್ನು ನಾಕ್ ಮಾಡಲು HTTP ಅನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು ಯಾರಾದರೂ ಈಗಾಗಲೇ ಈ ಕಾರ್ಯವನ್ನು ನಿರ್ವಹಿಸಿದ್ದಾರೆಯೇ ಎಂದು ಕೇಳುತ್ತಾರೆ. ಹೌದು ಎಂದಾದರೆ, ಅದು ಫಲಿತಾಂಶವನ್ನು ಸರಳವಾಗಿ ಡೌನ್‌ಲೋಡ್ ಮಾಡುತ್ತದೆ.

Gradle ರಿಮೋಟ್ ಕ್ಯಾಶ್ ಅನ್ನು ರನ್ ಮಾಡುವುದು ಸುಲಭ ಏಕೆಂದರೆ Gradle ಒಂದು ಡಾಕರ್ ಚಿತ್ರವನ್ನು ಒದಗಿಸುತ್ತದೆ. ನಾವು ಇದನ್ನು ಮೂರು ಗಂಟೆಗಳಲ್ಲಿ ನಿರ್ವಹಿಸಿದ್ದೇವೆ.

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

ಕ್ಯಾಶ್ ಮಿಸ್ಸ್ ಗ್ರಾಫ್ ಕೆಳಗೆ ಇದೆ.

ಪ್ರಾರಂಭದಲ್ಲಿ, ಕ್ಯಾಶ್ ಮಿಸ್‌ಗಳ ಶೇಕಡಾವಾರು ಪ್ರಮಾಣವು ಸುಮಾರು 65 ಆಗಿತ್ತು. ಮೂರು ವಾರಗಳ ನಂತರ, ನಾವು ಈ ಮೌಲ್ಯವನ್ನು 20% ಗೆ ಹೆಚ್ಚಿಸುವಲ್ಲಿ ಯಶಸ್ವಿಯಾಗಿದ್ದೇವೆ. ಆಂಡ್ರಾಯ್ಡ್ ಅಪ್ಲಿಕೇಶನ್ ಸಂಗ್ರಹಿಸುವ ಕಾರ್ಯಗಳು ವಿಚಿತ್ರವಾದ ಟ್ರಾನ್ಸಿಟಿವ್ ಅವಲಂಬನೆಗಳನ್ನು ಹೊಂದಿವೆ ಎಂದು ಅದು ಬದಲಾಯಿತು, ಇದರಿಂದಾಗಿ ಗ್ರ್ಯಾಡಲ್ ಸಂಗ್ರಹವನ್ನು ಕಳೆದುಕೊಂಡಿತು.

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

ಪರಿಣಾಮ ವಿಶ್ಲೇಷಣೆ

ಪುಲ್ ವಿನಂತಿಯ ಮೇರೆಗೆ, ನಾವು ಜಿಟ್ ಡಿಫ್ ಅನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ ಮತ್ತು ಮಾರ್ಪಡಿಸಿದ ಗ್ರೇಡಲ್ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಹುಡುಕುತ್ತೇವೆ.

ಬದಲಾದ ಮಾಡ್ಯೂಲ್‌ಗಳು ಮತ್ತು ಅವುಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವ ಎಲ್ಲಾ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸುವ ಉಪಕರಣ ಪರೀಕ್ಷೆಗಳನ್ನು ಮಾತ್ರ ನಡೆಸುವುದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ. ನೆರೆಯ ಮಾಡ್ಯೂಲ್ಗಳಿಗಾಗಿ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುವುದರಲ್ಲಿ ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ: ಅಲ್ಲಿ ಕೋಡ್ ಬದಲಾಗಿಲ್ಲ ಮತ್ತು ಏನೂ ಮುರಿಯಲು ಸಾಧ್ಯವಿಲ್ಲ.

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

ಉಪಕರಣ ಪರೀಕ್ಷೆಗಳ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡುವುದರಿಂದ ಅವರು ಒಳಗೊಂಡಿರುವ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಮಾತ್ರ ಪರೀಕ್ಷಿಸಲು ಸುಮಾರು ಎಂಟು ವಾರಗಳನ್ನು ತೆಗೆದುಕೊಂಡರು.

ತಪಾಸಣೆಯನ್ನು ವೇಗಗೊಳಿಸುವ ಕ್ರಮಗಳು ಯಶಸ್ವಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿವೆ. 45 ನಿಮಿಷಗಳಿಂದ ನಾವು ಸುಮಾರು 15 ಕ್ಕೆ ಏರಿದೆವು. ನಿರ್ಮಾಣಕ್ಕಾಗಿ ಒಂದು ಗಂಟೆಯ ಕಾಲು ಕಾಯುವುದು ಈಗಾಗಲೇ ಸಾಮಾನ್ಯವಾಗಿದೆ.

ಆದರೆ ಈಗ ಡೆವಲಪರ್‌ಗಳು ಯಾವ ಬಿಲ್ಡ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತಿದೆ, ಲಾಗ್ ಅನ್ನು ಎಲ್ಲಿ ನೋಡಬೇಕು, ಬಿಲ್ಡ್ ಏಕೆ ಕೆಂಪು ಬಣ್ಣದ್ದಾಗಿದೆ, ಯಾವ ಪರೀಕ್ಷೆ ವಿಫಲವಾಗಿದೆ ಇತ್ಯಾದಿಗಳು ಅರ್ಥವಾಗುತ್ತಿಲ್ಲ ಎಂದು ದೂರಲು ಪ್ರಾರಂಭಿಸಿದ್ದಾರೆ.

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

ವಿವರವಾದ ಪ್ರತಿಕ್ರಿಯೆಗಾಗಿ ಆರು ವಾರಗಳನ್ನು ಕಳೆಯಲಾಯಿತು.

ಯೋಜನೆಗಳು

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

ಇದಲ್ಲದೆ, ಇತರ ಯೋಜನೆಗಳಿವೆ.

• ರಿಟರ್ನ್ ಲಿಂಟ್ (ಮತ್ತು ಇತರ ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆ). ನಾವು ಈಗಾಗಲೇ ಈ ದಿಕ್ಕಿನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇವೆ.
• PR ಬ್ಲಾಕರ್‌ನಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ರನ್ ಮಾಡಿ ಅಂತ್ಯದಿಂದ ಕೊನೆಯವರೆಗೆ ಪರೀಕ್ಷೆಗಳು ಎಲ್ಲಾ SDK ಆವೃತ್ತಿಗಳಲ್ಲಿ.

ಆದ್ದರಿಂದ, ನಾವು Avito ನಲ್ಲಿ ನಿರಂತರ ಏಕೀಕರಣದ ಅಭಿವೃದ್ಧಿಯ ಇತಿಹಾಸವನ್ನು ಪತ್ತೆಹಚ್ಚಿದ್ದೇವೆ. ಈಗ ನಾನು ಅನುಭವಿ ದೃಷ್ಟಿಕೋನದಿಂದ ಕೆಲವು ಸಲಹೆಗಳನ್ನು ನೀಡಲು ಬಯಸುತ್ತೇನೆ.

ಸಲಹೆಗಳು

ನಾನು ಕೇವಲ ಒಂದು ಸಲಹೆಯನ್ನು ನೀಡಬಹುದಾದರೆ ಅದು ಹೀಗಿರುತ್ತದೆ:

ದಯವಿಟ್ಟು ಶೆಲ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳೊಂದಿಗೆ ಜಾಗರೂಕರಾಗಿರಿ!

ಬ್ಯಾಷ್ ತುಂಬಾ ಹೊಂದಿಕೊಳ್ಳುವ ಮತ್ತು ಶಕ್ತಿಯುತ ಸಾಧನವಾಗಿದೆ, ಇದು ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಬರೆಯಲು ತುಂಬಾ ಅನುಕೂಲಕರ ಮತ್ತು ವೇಗವಾಗಿದೆ. ಆದರೆ ನೀವು ಅದರೊಂದಿಗೆ ಬಲೆಗೆ ಬೀಳಬಹುದು, ಮತ್ತು, ದುರದೃಷ್ಟವಶಾತ್, ನಾವು ಅದರಲ್ಲಿ ಬಿದ್ದಿದ್ದೇವೆ.

ಇದು ನಮ್ಮ ನಿರ್ಮಾಣ ಯಂತ್ರಗಳಲ್ಲಿ ನಡೆಯುವ ಸರಳ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಯಿತು:

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

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

ಅಂತಹ ಲಿಪಿಗಳ ಅಭಿವೃದ್ಧಿಗೆ ಕಾರ್ಮಿಕ ವೆಚ್ಚವನ್ನು ನೀವು ಊಹಿಸಬಹುದು. ಈ ಬಲೆಗೆ ಬೀಳದಂತೆ ನಾನು ನಿಮಗೆ ಸಲಹೆ ನೀಡುತ್ತೇನೆ.

ಏನು ಬದಲಾಯಿಸಬಹುದು?

• ಯಾವುದೇ ಸ್ಕ್ರಿಪ್ಟಿಂಗ್ ಭಾಷೆ. ಬರೆಯಲು ಪೈಥಾನ್ ಅಥವಾ ಕೋಟ್ಲಿನ್ ಸ್ಕ್ರಿಪ್ಟ್ ಹೆಚ್ಚು ಅನುಕೂಲಕರ ಏಕೆಂದರೆ ಇದು ಪ್ರೋಗ್ರಾಮಿಂಗ್, ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳಲ್ಲ.
• ಅಥವಾ ರೂಪದಲ್ಲಿ ಎಲ್ಲಾ ನಿರ್ಮಾಣ ತರ್ಕವನ್ನು ವಿವರಿಸಿ ಕಸ್ಟಮ್ ಗ್ರ್ಯಾಡ್ಲ್ ಕಾರ್ಯಗಳು ನಿಮ್ಮ ಯೋಜನೆಗಾಗಿ.

ನಾವು ಎರಡನೇ ಆಯ್ಕೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ಮತ್ತು ಈಗ ನಾವು ಎಲ್ಲಾ ಬ್ಯಾಷ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ವ್ಯವಸ್ಥಿತವಾಗಿ ಅಳಿಸುತ್ತಿದ್ದೇವೆ ಮತ್ತು ಬಹಳಷ್ಟು ಕಸ್ಟಮ್ ಗ್ರ್ಯಾಡಲ್ ಕಾರ್ಯಗಳನ್ನು ಬರೆಯುತ್ತಿದ್ದೇವೆ.

ಸಲಹೆ #2: ಮೂಲಸೌಕರ್ಯವನ್ನು ಕೋಡ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಿ.

ನಿರಂತರ ಏಕೀಕರಣ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಜೆಂಕಿನ್ಸ್ ಅಥವಾ ಟೀಮ್‌ಸಿಟಿ ಇತ್ಯಾದಿಗಳ UI ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸದೆ, ಆದರೆ ನೇರವಾಗಿ ಪ್ರಾಜೆಕ್ಟ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಪಠ್ಯ ಫೈಲ್‌ಗಳ ರೂಪದಲ್ಲಿ ಸಂಗ್ರಹಿಸಿದಾಗ ಇದು ಅನುಕೂಲಕರವಾಗಿರುತ್ತದೆ. ಇದು ಆವೃತ್ತಿಯನ್ನು ನೀಡುತ್ತದೆ. ಇನ್ನೊಂದು ಶಾಖೆಯಲ್ಲಿ ಕೋಡ್ ಅನ್ನು ರೋಲ್‌ಬ್ಯಾಕ್ ಮಾಡಲು ಅಥವಾ ನಿರ್ಮಿಸಲು ಕಷ್ಟವಾಗುವುದಿಲ್ಲ.

ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಯೋಜನೆಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಬಹುದು. ಪರಿಸರದೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕು?

ಸಲಹೆ #3: ಡಾಕರ್ ಪರಿಸರಕ್ಕೆ ಸಹಾಯ ಮಾಡಬಹುದು.

ಇದು ಖಂಡಿತವಾಗಿಯೂ Android ಡೆವಲಪರ್‌ಗಳಿಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ; ದುರದೃಷ್ಟವಶಾತ್ 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

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

ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಲು ಎರಡು ಪ್ರಮುಖ ಕಾರಣಗಳೆಂದರೆ ಸ್ಕೇಲೆಬಿಲಿಟಿ ಮತ್ತು ಪುನರಾವರ್ತನೀಯತೆ. ಡಾಕರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು, ನೀವು ಒಂದು ಡಜನ್ ಬಿಲ್ಡ್ ಏಜೆಂಟ್‌ಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಸಂಗ್ರಹಿಸಬಹುದು, ಅದು ಹಿಂದಿನ ಪರಿಸರದಂತೆಯೇ ಇರುತ್ತದೆ. ಇದು ಸಿಐ ಎಂಜಿನಿಯರ್‌ಗಳ ಜೀವನವನ್ನು ಹೆಚ್ಚು ಸುಲಭಗೊಳಿಸುತ್ತದೆ. Android-sdk ಅನ್ನು ಡಾಕರ್‌ಗೆ ತಳ್ಳುವುದು ತುಂಬಾ ಸುಲಭ, ಆದರೆ ಎಮ್ಯುಲೇಟರ್‌ಗಳೊಂದಿಗೆ ಇದು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿದೆ: ನೀವು ಸ್ವಲ್ಪ ಕಷ್ಟಪಟ್ಟು ಕೆಲಸ ಮಾಡಬೇಕಾಗುತ್ತದೆ (ಅಥವಾ ಮುಗಿದದ್ದನ್ನು GitHub ನಿಂದ ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ).

ಸಲಹೆ ಸಂಖ್ಯೆ 4: ತಪಾಸಣೆಗಾಗಿ ತಪಾಸಣೆಗಳನ್ನು ಮಾಡಲಾಗುವುದಿಲ್ಲ, ಆದರೆ ಜನರಿಗೆ ಎಂಬುದನ್ನು ಮರೆಯಬೇಡಿ.

ತ್ವರಿತ ಮತ್ತು, ಮುಖ್ಯವಾಗಿ, ಸ್ಪಷ್ಟ ಪ್ರತಿಕ್ರಿಯೆಯು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ: ಯಾವುದು ಮುರಿದುಹೋಯಿತು, ಯಾವ ಪರೀಕ್ಷೆಯು ವಿಫಲವಾಗಿದೆ, ನಾನು ಬಿಲ್ಡ್‌ಲಾಗ್ ಅನ್ನು ಎಲ್ಲಿ ನೋಡಬಹುದು.

ಸಲಹೆ #5: ನಿರಂತರ ಏಕೀಕರಣವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವಾಗ ಪ್ರಾಯೋಗಿಕವಾಗಿರಿ.

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

ಸಲಹೆ #6: ಸಿದ್ಧ ಸಾಧನಗಳನ್ನು ಬಳಸಿ.

ಕ್ಲೌಡ್ ಸಿಐ ಅನ್ನು ಒದಗಿಸುವ ಅನೇಕ ಕಂಪನಿಗಳು ಈಗ ಇವೆ.

ಸಣ್ಣ ತಂಡಗಳಿಗೆ ಇದು ಉತ್ತಮ ಪರಿಹಾರವಾಗಿದೆ. ನೀವು ಏನನ್ನೂ ಬೆಂಬಲಿಸುವ ಅಗತ್ಯವಿಲ್ಲ, ಸ್ವಲ್ಪ ಹಣವನ್ನು ಪಾವತಿಸಿ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿರ್ಮಿಸಿ ಮತ್ತು ಉಪಕರಣ ಪರೀಕ್ಷೆಗಳನ್ನು ಸಹ ರನ್ ಮಾಡಿ.

ಸಲಹೆ #7: ದೊಡ್ಡ ತಂಡದಲ್ಲಿ, ಮನೆಯೊಳಗಿನ ಪರಿಹಾರಗಳು ಹೆಚ್ಚು ಲಾಭದಾಯಕವಾಗಿವೆ.

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

ಅರ್ಥಶಾಸ್ತ್ರವು ನಿರಂತರ ಏಕೀಕರಣ ಸೇರಿದಂತೆ ನಮ್ಮ ಸಂಪೂರ್ಣ ಜೀವನವನ್ನು ವಿವರಿಸುತ್ತದೆ. ನಮ್ಮ ನಿರಂತರ ಏಕೀಕರಣದ ಅಭಿವೃದ್ಧಿಯ ಪ್ರತಿ ಹಂತಕ್ಕೂ ನಾನು ಕಾರ್ಮಿಕ ವೆಚ್ಚಗಳ ವೇಳಾಪಟ್ಟಿಯನ್ನು ನಿರ್ಮಿಸಿದೆ.

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

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

• ಆಟೋಮೇಷನ್ ದುಬಾರಿಯಾಗಿದೆ. ಕಾರ್ಮಿಕ ವೇಳಾಪಟ್ಟಿಯನ್ನು ನೆನಪಿಡಿ.
• ಯಾಂತ್ರೀಕರಣಕ್ಕೆ ಬಂದಾಗ, ಜನರು ತಪ್ಪುಗಳನ್ನು ಮಾಡುತ್ತಾರೆ.
• ಕೆಲವೊಮ್ಮೆ ಇದು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ತುಂಬಾ ಸೋಮಾರಿಯಾಗಿದೆ, ಏಕೆಂದರೆ ಎಲ್ಲವೂ ಆ ರೀತಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಬೇರೆ ಯಾವುದನ್ನಾದರೂ ಏಕೆ ಸುಧಾರಿಸಬೇಕು, ಈ ನಿರಂತರ ಏಕೀಕರಣ ಏಕೆ?

ಆದರೆ ನನ್ನ ಬಳಿ ಅಂಕಿಅಂಶಗಳಿವೆ: 20% ಅಸೆಂಬ್ಲಿಗಳಲ್ಲಿ ದೋಷಗಳು ಸಿಕ್ಕಿಬೀಳುತ್ತವೆ. ಮತ್ತು ನಮ್ಮ ಡೆವಲಪರ್‌ಗಳು ಕೋಡ್ ಅನ್ನು ಕಳಪೆಯಾಗಿ ಬರೆಯಲು ಕಾರಣವಲ್ಲ. ಏಕೆಂದರೆ ಡೆವಲಪರ್‌ಗಳು ಏನಾದರೂ ತಪ್ಪು ಮಾಡಿದರೆ, ಅದು ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುವುದಿಲ್ಲ, ಅದು ಸ್ವಯಂಚಾಲಿತ ತಪಾಸಣೆಯಿಂದ ಸಿಕ್ಕಿಬೀಳುತ್ತದೆ ಎಂಬ ವಿಶ್ವಾಸವಿದೆ. ಅಂತೆಯೇ, ಡೆವಲಪರ್‌ಗಳು ಸ್ಥಳೀಯವಾಗಿ ಏನನ್ನಾದರೂ ಚಲಾಯಿಸುವ ಮತ್ತು ಪರೀಕ್ಷಿಸುವ ಬದಲು ಕೋಡ್ ಮತ್ತು ಆಸಕ್ತಿದಾಯಕ ವಿಷಯಗಳನ್ನು ಬರೆಯಲು ಹೆಚ್ಚು ಸಮಯವನ್ನು ಕಳೆಯಬಹುದು.

ನಿರಂತರ ಏಕೀಕರಣವನ್ನು ಅಭ್ಯಾಸ ಮಾಡಿ. ಆದರೆ ಮಿತವಾಗಿ.

ಅಂದಹಾಗೆ, ನಿಕೊಲಾಯ್ ನೆಸ್ಟೆರೊವ್ ಸ್ವತಃ ಉತ್ತಮ ವರದಿಗಳನ್ನು ನೀಡುವುದಲ್ಲದೆ, ಕಾರ್ಯಕ್ರಮ ಸಮಿತಿಯ ಸದಸ್ಯರೂ ಆಗಿದ್ದಾರೆ. AppsConf ಮತ್ತು ನಿಮಗಾಗಿ ಅರ್ಥಪೂರ್ಣ ಭಾಷಣಗಳನ್ನು ತಯಾರಿಸಲು ಇತರರಿಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಮುಂದಿನ ಸಮ್ಮೇಳನ ಕಾರ್ಯಕ್ರಮದ ಸಂಪೂರ್ಣತೆ ಮತ್ತು ಉಪಯುಕ್ತತೆಯನ್ನು ವಿಷಯಗಳ ಮೂಲಕ ನಿರ್ಣಯಿಸಬಹುದು ವೇಳಾಪಟ್ಟಿ. ಮತ್ತು ವಿವರಗಳಿಗಾಗಿ, ಏಪ್ರಿಲ್ 22-23 ರಂದು ಇನ್ಫೋಸ್ಪೇಸ್‌ಗೆ ಬನ್ನಿ.

ಮೂಲ: www.habr.com