There was a quote (pg 9) that rang true to me related to process subversion that was an antipattern. This is something that requires a cultural shift to overcome.
As pressure increases the defined process for collaboration between the development and deployment teams is subverted in order to get the deployment done within the time allocated to the deployment team
The benefit of "random pieces of poorly understood" infra is not solved via configuration management -- now we have random pieces of poorly understood puppet.
We add in configuration at deploy-time for services with scap3, this works well for them. I think this is also the model of k8s.
There is very little visibility into our testing env (deployment-prep) for anyone
We use Puppet to enforce existing state and tweak existing systems rather than provision from scratch
Chapter 3
Without CI, your application is broken until you prove otherwise. With CI, the default state of your application is working, albeit with a level of confidence that depnds upon the extent of your automated test coverge
The "short build" section is much less than we currently have
"commit" stage is "test"
"acceptance" stage is "gate-and-submit"
some portion of "gate-and-submit" should likely become post-merge
The problem with post-merge tests is how to fix them
this is part of the cultural shift
we haven't checked in with folks about this kind of thing...ever (as long as I've been around)
I think we enforce this with gating, gating is our hammer
Distributed Teams
Another place that we, in some ways, outpace the book
We don't get all the benefits of a central CI-system (self-serve, metrics)
What metrics should we be gathering as part of the deployment pipeline, right now?
it is essential that development teams can easily self-service new environments, configurations, builds, and deployments in an automated fashion (pg 76)
Distributed VCS
The pace of development tends to be faster on GitHub {{cn}}
Chapter 4
We generally class comprehensive as greater than 80% code coverage.
Seems to be a huge emphasis on cucumber tests
Done badly, [acceptance tests] can inflict a significant cosst on your delivery team (pg 87)
Why not devlopers writing tests
In our ideal project, testers collaborate with developers and users to write automated tests from the start of the project (pg 83)
we use swagger tests as acceptance tests (deployment smoke tests) for services and mediawiki
This really deemphasises unit/component tests, is this only because it's hard to explain in business terms? Do we have that problem?