Optistream ತನ್ನ ಒಂದು ಸಾವಿರಕ್ಕೂ ಹೆಚ್ಚು ಸಾರ್ವಜನಿಕ ಪುಟಗಳ SEO ಅನ್ನು ಕಳೆದುಕೊಳ್ಳದೆಯೇ, ಹನ್ನೆರಡು ಕಸ್ಟಮ್ WordPress ಪ್ಲಗಿನ್ಗಳನ್ನು ಒಂದೇ ಕೋಡ್ಬೇಸ್ಗೆ (codebase) ವಿಲೀನಗೊಳಿಸಿತು.
ಈ ವಿಲೀನ ಏಕೆ ಮುಖ್ಯವಾಗಿತ್ತು
ಸಾಮಾನ್ಯ WordPress ಸೈಟ್ಗಳಲ್ಲಿ ಕೆಲವು ಪ್ಲಗಿನ್ಗಳಿರುತ್ತವೆ; ಆದರೆ ದೊಡ್ಡ ಸೈಟ್ಗಳು ವೈರ್ಗಳಿಂದ ತುಂಬಿದ ವರ್ಕ್ಶಾಪ್ನಂತೆ ಕಾಣುತ್ತವೆ, ಪ್ರತಿಯೊಂದೂ ಕೆಲಸ ಮಾಡುತ್ತಿರುತ್ತದೆ ಆದರೆ ಯಾವುದನ್ನೂ ಸುಲಭವಾಗಿ ಅನ್ಪ್ಲಗ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. Optistream ಸೈಟ್ ಸ್ಟ್ರೀಮರ್ ಪ್ರೊಫೈಲ್ಗಳು, ಇ-ಸ್ಪೋರ್ಟ್ಸ್ (esports) ತಂಡಗಳು ಮತ್ತು ಗೇಮ್ ಡೇಟಾವನ್ನು ನಿರ್ವಹಿಸುವ ಹನ್ನೆರಡು ವಿಶೇಷ (bespoke) ಪ್ಲಗಿನ್ಗಳನ್ನು ಹೊಂದಿತ್ತು. ಆ ಪ್ಲಗಿನ್ಗಳು ಸಾವಿರಾರು ಇಂಡೆಕ್ಸಬಲ್ (indexable) ಪುಟಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತಿದ್ದವು. ಆ URLಗಳನ್ನು ಹಾಗೆಯೇ ಉಳಿಸಿಕೊಳ್ಳುವುದು ಅನಿವಾರ್ಯವಾಗಿತ್ತು—ಯಾವುದೇ ಬದಲಾವಣೆಯು ಮೈಗ್ರೇಷನ್ (migration) ಪ್ರಕ್ರಿಯೆಯನ್ನು ವಿಫಲಗೊಳಿಸಬಹುದಿತ್ತು.
ಹಳೆಯ ಸೆಟಪ್ ಹೇಗಿತ್ತು
ಹನ್ನೆರಡು ಪ್ಲಗಿನ್ಗಳು ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ ಆದ ಫೋಲ್ಡರ್ನಲ್ಲಿ ಇದ್ದವು, ತನ್ನದೇ ಆದ ಕಸ್ಟಮ್ ಪೋಸ್ಟ್ ಟೈಪ್ ಅನ್ನು ನೋಂದಾಯಿಸುತ್ತಿದ್ದವು ಮತ್ತು ವಿವಿಧ ಬಿಂದುಗಳಲ್ಲಿ WordPress ಗೆ ಹೂಕ್ (hook) ಆಗಿದ್ದವು. ಸಮಸ್ಯೆಗಳು ಒಂದಾದಂತೆ ಹೆಚ್ಚಾಗುತ್ತಿದ್ದವು:
- Hooks ಮತ್ತು assets ಹರಡಿಕೊಂಡಿದ್ದವು, ಇದರಿಂದ ಯಾವ ಕೋಡ್ ಯಾವಾಗ ಚಲಿಸುತ್ತದೆ ಎಂದು ಊಹಿಸುವುದು ಕಷ್ಟವಾಗುತ್ತಿತ್ತು.
- ರೂಟಿಂಗ್ ಲಾಜಿಕ್ (Routing logic) ಅನೇಕ ಪ್ರತ್ಯೇಕ ಫೈಲ್ಗಳಲ್ಲಿ ಇತ್ತು, ಆದ್ದರಿಂದ ಒಂದು URL ಹಲವಾರು ಪ್ಲಗಿನ್ಗಳಿಂದ ಪ್ರಭಾವಿತವಾಗುತ್ತಿತ್ತು.
- CSS ಫೈಲ್ಗಳು ಅನಿರೀಕ್ಷಿತ ಕ್ರಮದಲ್ಲಿ ಲೋಡ್ ಆಗುತ್ತಿದ್ದವು, ಇದು ಸ್ಟೈಲ್ ಸಂಘರ್ಷಗಳಿಗೆ (style clashes) ಕಾರಣವಾಗುತ್ತಿತ್ತು.
- ಡಿಬಗ್ ಮಾಡಲು (Debugging) ಹನ್ನೆರಡು ವಿಭಿನ್ನ ಡೈರೆಕ್ಟರಿಗಳನ್ನು ತೆರೆಯಬೇಕಾಗುತ್ತಿತ್ತು, ಇದು ಯಾವುದೇ ಡೆವಲಪರ್ಗೆ ಸಮಯದ ವ್ಯರ್ಥವಾಗಿತ್ತು.
ಗುರಿ ಫೈಲ್ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುವುದಾಗಿರಲಿಲ್ಲ; ಬದಲಾಗಿ ಇಡೀ ವ್ಯವಸ್ಥೆಗೆ ಒಂದೇ ಲೈಫ್ಸೈಕಲ್ (lifecycle) ಮತ್ತು ಡಿಪೆಂಡೆನ್ಸಿಗಳನ್ನು (dependencies) ನಿರ್ವಹಿಸಲು ಒಂದೇ ಸ್ಥಳವನ್ನು ಒದಗಿಸುವುದು ಆಗಿತ್ತು.
ಮೈಗ್ರೇಷನ್ ಅನ್ನು ಹೇಗೆ ಯೋಜಿಸಲಾಯಿತು
ತಂಡವು ಸಾರ್ವಜನಿಕ ಇಂಟರ್ಫೇಸ್—URLಗಳು, ಟೆಂಪ್ಲೇಟ್ಗಳು ಮತ್ತು ಮೆಟಾ ಡೇಟಾವನ್ನು—ಮುರಿಯಲಾಗದ ಒಪ್ಪಂದದಂತೆ ಪರಿಗಣಿಸಿತು. ಫ್ರಂಟ್ ಎಂಡ್ನಲ್ಲಿ (front end) ಏನಾದರೂ ಬದಲಾವಣೆಯಾದರೆ ಅದು ವೈಫಲ್ಯವೆಂದೇ ಪರಿಗಣಿಸಲಾಗುತ್ತಿತ್ತು. ಆ ನಿಯಮವನ್ನು ನೆನಪಿನಲ್ಲಿಟ್ಟುಕೊಂಡು, ಅವರು ಪ್ರತಿ ಹಂತದ ನಂತರ ಪಾಲಿಸಬೇಕಾದ ಚೆಕ್ಲಿಸ್ಟ್ ಅನ್ನು ಸಿದ್ಧಪಡಿಸಿದರು.
1. ಸಾರ್ವಜನಿಕ ಒಪ್ಪಂದಗಳ ಪಟ್ಟಿ ಮಾಡಿ
ಪ್ರತಿಯೊಂದು URL ಪಾತ್ (path), ಅದರ ಪೋಸ್ಟ್ ಟೈಪ್, ರಿರೈಟ್ ಸ್ಲಗ್ (rewrite slug), ಟೆಂಪ್ಲೇಟ್ ಫೈಲ್ ಮತ್ತು ಅದು ಅವಲಂಬಿಸಿರುವ ಮೆಟಾ ಕೀಲಿಗಳನ್ನು (meta keys) ಬರೆದಿಡಲಾಯಿತು. ಈ ಸ್ಪ್ರೆಡ್ಶೀಟ್ ನಿಯಮಾವಳಿಯಂತೆ ಕೆಲಸ ಮಾಡಿತು: ಒಂದು ಮಾಡ್ಯೂಲ್ ಸ್ಥಳಾಂತರಗೊಂಡ ನಂತರ URL ಬದಲಾದರೆ, ಮೈಗ್ರೇಷನ್ ಅನ್ನು ಹಿಂದಕ್ಕೆ ಪಡೆಯಲಾಗುತ್ತಿತ್ತು (rolled back).
2. ಸರಳ ಲೋಡರ್ ಅನ್ನು ನಿರ್ಮಿಸಿ
ಒಂದು ಸಣ್ಣ ಬೂಟ್ಸ್ಟ್ರಾಪ್ (bootstrap) ಫೈಲ್ ಅನ್ನು ರಚಿಸಲಾಯಿತು. ಪ್ರತಿಯೊಂದು ಹಳೆಯ ಪ್ಲಗಿನ್ ಈಗ ಒಂದು ಊಹಿಸಬಹುದಾದ ಫಂಕ್ಷನ್ ಹೆಸರಿನ ಮೂಲಕ ಒಂದೇ "content domain" ಅನ್ನು ನೋಂದಾಯಿಸುತ್ತದೆ. ಲೋಡರ್ ಯಾವುದೇ ಸಂಕೀರ್ಣ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ—ಅಗತ್ಯವಿದ್ದಾಗ ಸರಿಯಾದ ಮಾಡ್ಯೂಲ್ ಅನ್ನು WordPress ಗೆ ತರಲು ಅಷ್ಟೇ ಮಾಡುತ್ತದೆ. ಸರಳತೆಯು ವೈಫಲ್ಯಗಳನ್ನು ಸುಲಭವಾಗಿ ಗುರುತಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
3. ಡೇಟಾವನ್ನು ರಕ್ಷಿಸಿ
ಮೆಟಾ ಕೀಲಿಗಳನ್ನು ಮರುನಾಮಕರಣ ಮಾಡುವುದು ಕೋಡ್ ಬದಲಾವಣೆಯನ್ನು ಡೇಟಾ ಮೈಗ್ರೇಷನ್ ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತಿತ್ತು ಮತ್ತು ಅನಗತ್ಯ ಅಪಾಯವನ್ನು ಹೆಚ್ಚಿಸುತ್ತಿತ್ತು. ಹಳೆಯ ಕೀಲಿಗಳನ್ನು ಹಾಗೆಯೇ ಉಳಿಸಿಕೊಳ್ಳಲಾಯಿತು; ಹೊಸ ಹೆಲ್ಪರ್ ಫಂಕ್ಷನ್ಗಳು ಅವುಗಳನ್ನು ಸುತ್ತುವರಿಯುತ್ತವೆ (wrap), ಇದರಿಂದ ಡೇಟಾಬೇಸ್ ಸ್ಕೀಮಾ (database schema) ಸ್ಥಿರವಾಗಿರುತ್ತದೆ.
4. CSS ಮಾಲೀಕತ್ವವನ್ನು ಸರಿಪಡಿಸಿ
ಸ್ಟೈಲಿಂಗ್ ಸಂಘರ್ಷಗಳನ್ನು ಮೂರು ಕ್ರಮಗಳ ಮೂಲಕ ಪರಿಹರಿಸಲಾಯಿತು:
- ಮಾಡ್ಯೂಲ್ CSS ಫೈಲ್ಗಳನ್ನು ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯೊಂದಿಗೆ ಎನ್ಕ್ಯೂ (enqueue) ಮಾಡಲಾಗುತ್ತದೆ, ಇದರಿಂದ ಅವು ಕೊನೆಯಲ್ಲಿ ಲೋಡ್ ಆಗುತ್ತವೆ.
- ಎಲ್ಲಾ ಸೆಲೆಕ್ಟರ್ಗಳನ್ನು (selectors) ಪ್ರತಿಯೊಂದು ಮಾಡ್ಯೂಲ್ಗೆ ವಿಶಿಷ್ಟವಾದ ವ್ರ್ಯಾಪರ್ ಕ್ಲಾಸ್ಗೆ (wrapper class) ಸೀಮಿತಗೊಳಿಸಲಾಗಿದೆ (scoped).
- ಸ್ಟೈಲ್ಶೀಟ್ ಬದಲಾದಾಗ ಬ್ರೌಸರ್ ಕ್ಯಾಶೆಗಳನ್ನು (browser caches) ಅಳಿಸಲು ಎನ್ಕ್ಯೂ ಮಾಡುವಾಗ
filemtime()ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.
5. ಸುರಕ್ಷಿತ ಲೂಪ್ ಬಳಸಿ
ಮೈಗ್ರೇಷನ್ ಪ್ರಕ್ರಿಯೆಯು ಒಂದೊಂದೇ ಮಾಡ್ಯೂಲ್ ಮೂಲಕ ಸಾಗಿತು. ಒಂದು ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಸ್ಥಳಾಂತರಿಸಿದ ನಂತರ, ತಂಡವು ಮುಂದಿನ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಪೋಸ್ಟ್-ಟೈಪ್ ನೋಂದಣಿ, ರೂಟಿಂಗ್ ಮತ್ತು ಮೊಬೈಲ್ ಲೇಔಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿತು. ಮೂಲ ಪ್ಲಗಿನ್ಗಳು ಇನ್ಸ್ಟಾಲ್ ಆಗಿದ್ದವು ಆದರೆ ಅಸಕ್ರಿಯವಾಗಿದ್ದವು (inactive), ಇದು ತಕ್ಷಣವೇ ಹಿಂದಕ್ಕೆ ಪಡೆಯಲು (rollback) ಅನುವು ಮಾಡಿಕೊಟ್ಟಿತು.
ಪ್ರೊಡಕ್ಷನ್ ಚೆಕ್ಲಿಸ್ಟ್
ಪ್ರತಿ ಮಾಡ್ಯೂಲ್ ಬದಲಾವಣೆಯ ನಂತರ ತಂಡವು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಪರಿಶೀಲಿಸಿತು:
- ಪ್ರತಿಯೊಂದು ಕಂಟೆಂಟ್-ಟೈಪ್ URL ಕೂಡ 200 HTTP ಸ್ಟೇಟಸ್ ಅನ್ನು ನೀಡುತ್ತದೆ.
- ಕ್ಯಾನೊನಿಕಲ್ (canonical) URL ಹೆಡರ್ ಮೂಲ URL ಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ.
- ಪೇಜ್ ಶೀರ್ಷಿಕೆಗಳು ಮತ್ತು ಮೆಟಾ ವಿವರಣೆಗಳು ಬದಲಾಗಿಲ್ಲ.
- ಎಲ್ಲಾ ಚಿತ್ರಗಳು ಯಾವುದೇ ಬ್ರೋಕನ್ ಲಿಂಕ್ಗಳಿಲ್ಲದೆ ಲೋಡ್ ಆಗುತ್ತವೆ.
- ಮೊಬೈಲ್ ಪರ𝗱ೆಗಳಲ್ಲಿ ಯಾವುದೇ ಹಾರಿಜontal ಓವರ್ಫ್ಲೋ (horizontal overflow) ಕಾಣಿಸುವುದಿಲ್ಲ.
- ಬ್ರೌಸರ್ ಕನ್ಸೋಲ್ನಲ್ಲಿ ಯಾವುದೇ JavaScript ಅಥವಾ CSS ದೋಷಗಳು ಕಂಡುಬರುವುದಿಲ್ಲ.
ಚೆಕ್ಲಿಸ್ಟ್ ಪೂರ್ಣಗೊಂಡ ನಂತರವಷ್ಟೇ ತಂಡವು ಹಳೆಯ ಪ್ಲಗಿನ್ ಅನ್ನು ಶಾಶ್ವತವಾಗಿ ಅಸಕ್ರಿಯಗೊಳಿಸಿತು.
ಹೊಸ ಪ್ಲಗಿನ್ ಏನನ್ನು ನೀಡುತ್ತದೆ
ಇದರ ಪರಿಣಾಮವಾಗಿ ಬಂದ ಒಂದೇ ಪ್ಲಗಿನ್ ಕೋಡ್ಬೇಸ್ ಅನ್ನು ಕುಗ್ಗಿಸುವುದಿಲ್ಲ; ಅದು ಕೇವಲ ಗಡಿಗಳನ್ನು (boundaries) ಸ್ಪಷ್ಟಪಡಿಸುತ್ತದೆ. ಹನ್ನೆರಡು ಕಾರ್ಯಕ್ಷಮತೆಯ ಪ್ರದೇಶಗಳು ಈಗ ಒಂದೇ ಲೈಫ್ಸೈಕಲ್, ಒಂದೇ ಸೆಟ್ ಹೂಕ್ಗಳು ಮತ್ತು ಡಿಪೆಂಡೆನ್ಸಿಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಒಂದೇ ಸ್ಥಳವನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ. ಹೊಸ ಪ್ಲಗಿನ್ ವ್ಯವಸ್ಥೆಯನ್ನು ಚಿಕ್ಕದಾಗಿ ಮಾಡಲಿಲ್ಲ. ಅದು ಗಡಿಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ತೋರಿಸಿತು. ಇದು ಕಡಿಮೆ ಪ್ಲಗಿನ್ಗಳನ್ನು ಹೊಂದಿರುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಉಪಯುಕ್ತವೆಂದು ಸಾಬೀತಾಯಿತು.
ಅಪಾಯಗಳು ಮತ್ತು ಪ್ರತಿವಾದಗಳು
ಶಿಸ್ತುಬದ್ಧವಾದ 'ಕಾಂಟ್ರಾಕ್ಟ್-ಫಸ್ಟ್' (contract-first) ವಿಧಾನ ಮತ್ತು ಹಂತ ಹಂತವಾದ ಅನುಷ್ಠಾನವು ಅಪಾಯಗಳನ್ನು ನಿಯಂತ್ರಣದಲ್ಲಿಡಬಲ್ಲದು ಎಂದು Optistream ಪ್ರಕರಣವು ತೋರಿಸುತ್ತದೆ.
ಮುಂದೆ ಗಮನಿಸಬೇಕಾದವುಗಳು
ನೀವು ಇದೇ ರೀತಿಯ ಏಕೀಕರಣವನ್ನು ಪರಿಗಣಿಸುತ್ತಿದ್ದರೆ, ಈ ಎರಡು ಪ್ರಮುಖ ಅಂಶಗಳಿಂದ ಪ್ರಾರಂಭಿಸಿ:
- URL ಸ್ಥಿರತೆ (URL stability) – ನೀವು ಒಂದು ಸಾಲು ಕೋಡ್ ಬರೆಯುವ ಮೊದಲು ಪ್ರತಿಯೊಂದು ಸಾರ್ವಜನಿಕ ಪಾತ್ ಅನ್ನು ಮ್ಯಾಪ್ ಮಾಡಿ.
- ಡೇಟಾ ಸ್ಥಿರತೆ (Data stability) – ನೀವು ಪೂರ್ಣ ಪ್ರಮಾಣದ ಮೈಗ್ರೇಷನ್ಗೆ ಸಿದ್ಧರಾಗದ ಹೊರತು ಡೇಟಾಬೇಸ್ ಫೀಲ್ಡ್ಗಳನ್ನು ಮರುನಾಮಕರಣ ಮಾಡುವುದನ್ನು ತಪ್ಪಿಸಿ.
ಅಲ್ಲಿಂದ, ಒಂದು ಸಣ್ಣ ಲೋಡರ್ ಅನ್ನು ನಿರ್ಮಿಸಿ, CSS ಅನ್ನು ಸ್ಕೋಪ್ ಮಾಡಿ (scoped), ಮತ್ತು ಕಟ್ಟುನಿಟ್ಟಾದ ಪ್ರೊಡಕ್ಷನ್ ಚೆಕ್ಲಿಸ್ಟ್ ಅನ್ನು ಪಾಲಿಸುತ್ತಾ ಒಂದೊಂದೇ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಸ್ಥಳಾಂತರಿಸಿ.