Problems Adopting CI
Problem: End-of-day checkins breaking the build or production
- Background/Poll of Attendees:
- Some teams have very short CI windows (5 minutes), others doing nightlies
- Very few doing promoted/sequential builds/graduated pipelines
- Use local Jenkins instances in VMs that each dev can use to test their work before committing
- Favoring small, frequent commits over infrequent, big commits; needs education of devs to avoid siloing and holding on to code
- Use flaggable features to incrementally promote parts of a larger collection of features
- Mitigation proxies: route some small subset of traffic to new version/feature. Incrementally increase traffic over time until a problem arises or 100% of traffic is reached.
Question: What to do when CI can't keep up?
- Large amounts of customer data that doesn't match production
- Need to manage data in the same way as other configuration features
How to deal with configuration drift?
- e.g., tools/libraries/etc only on CI server or different from devs' version
- Configuration has to be the same!
- Build process could include check for needed configuration and installs it if not present
- Use VMs with exact needed configuration; create/destroy per build to guarantee no stale artifacts, etc.
How to maintain multiple software versions?
- Archive past versions to maintenance branches
- Bug fixes pushed to all branches and propagated up
- Realize that build team's customer is dev ops; know who your customer is.
- Customers are distinct from stakeholders
How to deal with limited rights on production servers?
- Understand that ops' primary fears are configuration drift & security
- Logs can be exported to a place accessible to devs/testers
- Oppositional culture (devs vs ops, testers vs devs) can play a role; avoid us vs. them thinking!
- Need to find ways of getting what you need without access; devs need to work with ops to get what is needed