Talk about “Continuous” something, do we really know what means?
Continuous Integration, Continuous Delivery, Continuous Deployment (stated here for SEO), what are they in my perspective ? I’m quality assurance engineer, “devops” (again, just for SEO) in an enterprise company that develop large scale applications for the Telco market, it is not SAAS products and our software come across long way until they get to a real users.
This talk is about the technicality of the common buzzwords in today software engineering practices, the new challenges and the pitfalls.
So, ( its gone be a long …) we break the monolithic application, moved to micro services (worship Martin Fowler), Dockerized and kubernetizing everything, modeliezed UI parts to NPM, restructured our technology stack, Git for all products assets, adhere unit tests and coverage reports, believe in contract tests, automate integration tests, addicting to Jenkins, hipchating all over, empower teams to “devops” culture, bring coachers to coach other coachers, deploy new “devops” silo team on top of the other silos, computing in the cloud, non-functional tests from day one, static code analysis for code violation/open sources licensing/security breaks, weekly/daily/hourly status meetings, spent millions to get external super experts to tell us what we know and are we ready to go ?
The level of success of whatever “Continuous releases” it is in essence the versioning approach of code repositories.
- Using the releases approach of “gitflow workflow” lead to an heavy maintenance process of releases branches, here a release (minor or major) is an event, branches are created for every releases, maintained by their own, need to merge down/up and a spaghetti branches are baked again. This oppose to “Continuous releases”.
- “Master/Features branch workflow”, which mean that every Pull Request from side branches to master is a potential release, that’s what we want.
What Next ?
Having tones of UI modules and micro services that interact with each other, sometimes even having indirect circular dependencies which managed as a separate pipelines is forcing a strict disciplined environment.
The moment a feature is rolling-up it must respect the following:
1. “Latest Master” is always Green.
2. “Latest Master” can be always released and consumed (ready as a release artifacts and not Snapshot).
3. “Latest Master” has passed all the gates that ensure quality.
4. “Latest Master” is fully BWC, no regression issues, fixes should be always made on latest source and not on historical branches.
5. “BWC” is not enough, the underneath code which interact with other modules need to keep support old contracts communications.
6. “Release” is a nonevent, meaning that no drop branches and no special activities should be made at end of drops.
7. Features can be toggled without effects on other functionality.
Probably now you get the point, the challenge of building core product that is fragmented to so many services, be a “Continuous Something” and in the end serve several customers implementations from latest “master branch” is a huge challenge that might bringing us back to square one very often.