Fork me on GitHub
#bof-arch-engineering-ops
<
2020-10-13
>
Adam Hawkins, SRE at Skillshare, smallbatches.fm Host19:10:31

Question for this group: what does “technical excellence” mean with regard to deployment pipelines?

Bryan Finster - Walmart (Speaker)20:10:33

No human touch. Defects detected very early in the flow. All security and compliance automated. "I trust that it's very hard for me to deliver the wrong thing." "I can deliver your change before you finish lunch".

👍 2
Ferrix Hovi - Head of DevOps - Siili20:10:43

"Delivery with speed AND quality is an engineering principle worth pride, not a constant debate."

Katrina Sison20:10:58

Interesting thought! Opsani will be talking about how you can have your cake and eat it too in our live demos! Learn about how you can have better performance, and lower cloud cost without compromosing on delivery speed. (https://pages.opsani.com/does-2020-live-demo-sign-up)

Adam Hawkins, SRE at Skillshare, smallbatches.fm Host20:10:18

> No human touch. Defects detected very early in the flow. All security and compliance automated. “I trust that it’s very hard for me to deliver the wrong thing.” “I can deliver your change before you finish lunch”. Seems like a great starting point. Then it’s just a question of how much is required to prove the absence of defects. I’d like to tack on the code running in production behind a feature flag automatically. This way things may be continuously deployed to production as “no ops”, then flipped on/off accordingly.

Ferrix Hovi - Head of DevOps - Siili20:10:43

Absence of defects is beside the point. Absolute absence costs an infinite amount and that is not desirable. hard to deliver wrong things and the high likelihood of being able to fix the rest is well enough.

Bryan Finster - Walmart (Speaker)20:10:44

You cannot prove the absence of defects. You can test that the things you know can fail don't.

Bryan Finster - Walmart (Speaker)20:10:17

Defect == the application is behaving in a way other than what the customer needs.

Adam Hawkins, SRE at Skillshare, smallbatches.fm Host20:10:23

> You can test that the things you know can fail don’t. That’s what I mean

Adam Hawkins, SRE at Skillshare, smallbatches.fm Host20:10:52

free of known regressions; defects found as early as possible

Bryan Finster - Walmart (Speaker)20:10:02

Well, the application isn't CURRENTLY failing.

Ferrix Hovi - Head of DevOps - Siili20:10:09

Building a test harness incrementally could be a solution.

Bryan Finster - Walmart (Speaker)20:10:50

If you have a legacy application. It's tested in production, but cannot safely be refactored.

Bryan Finster - Walmart (Speaker)20:10:37

Now you need to change it. Find the boundaries that the change will impact and test those boundaries. Then test for the new behavior and make the application do that. Rinse, repeat.

Bryan Finster - Walmart (Speaker)20:10:54

It's the only safe way to test untested code.

Dan Greenberg20:10:17

Afternoon, all! Love the discussion that is starting up already 😀 Here is the Zoom link for today's BoF session: https://excella.zoom.us/j/91040918326?pwd=SVZEaktBd1BON3RrUWJrMUtYcFkvUT09&amp;from=msft See you all in a bit!

Dan Greenberg21:10:22

Friendly reminder we are operating today's discussion using Chatham House Rules - When a meeting, or part thereof, is held under the Chatham House Rule, participants are free to use the information received, but neither the identity nor the affiliation of the speaker(s), nor that of any other participant, may be revealed. If you'd like to post your thoughts in this Slack channel… remember they should be non-attributable (per the Chatham House Rule).

Nick - developer at BNPP21:10:01

any particular topic we are going to talk about?

Dan Greenberg21:10:35

I didn't have a particular one queued up, wanted to see what's on everyone's minds!

Dan Greenberg22:10:02

Thanks all - great discussion! Here are some of my notes and feel free to continue the Q&A on Slack!

One Word to Describe Technical Excellence
Working
Quality
Thorough
Small

Test Driven Development
•	Small, incremental pieces
•	Junit, Mockito
•	Unit Test Coverage
•	Monolithic Applications

Struggles
•	Consistent technology (React, Python, .NET)
•	Cross-functionality between teams
•	AS400, COBOL  Microservices

Balance between standardization for consistency versus non-stifling of creativity
•	Standardization makes consistency and documentation easy
•	On the downside, some people can feel creativity and innovation are stifled

Enterprise Team
•	Cloud migration

Manual sign-offs
•	Gaps by having process broken out
•	Takes a very mature organization to have a push-button deployment to production

How would you design the development process from the ground up?
•	Idea 1
o	    Code using TDD
o	    Code gets pushed, runs through tests, continuously deployed
o	    Green/blue deployment pattern within the cloud
o	    Every environment has its own automated tests
o	    TDD, BDD
o	    CI/CD would alleviate the tradeoff (initial setup can take lots of time, CI/CD reduces that 
        time)
•	Idea 2
o	    OpenSource model
o	    Let teams succeed and fail on their own
o	    Trust the teams – they will iteratively change for the better as they realize what works and 
        what doesn't work
•	Idea 3
o	    Ease of use
o	    Visibility around consequences of your coding actions
	        Initial dev environment  knowing if something is successful in production
	        Use of features by customer

Source Control
•	Git, GitLab
•	TFS
•	Code Reviews

Training
•	Pair programming
•	Mob programming
•	Ping-pong development

Behavior Driven Development
•	Writing tests aligned with what the business would actually do with the product, rather than unit 
    tests
•	Can have a mix of BDD and TDD (test driven development)
•	BDD is more business-driven

Importance of Cross-Functionality – silos can enable the "they'll catch it downstream" mentality

Dan Greenberg22:10:02

Thanks all - great discussion! Here are some of my notes and feel free to continue the Q&A on Slack!

One Word to Describe Technical Excellence
Working
Quality
Thorough
Small

Test Driven Development
•	Small, incremental pieces
•	Junit, Mockito
•	Unit Test Coverage
•	Monolithic Applications

Struggles
•	Consistent technology (React, Python, .NET)
•	Cross-functionality between teams
•	AS400, COBOL  Microservices

Balance between standardization for consistency versus non-stifling of creativity
•	Standardization makes consistency and documentation easy
•	On the downside, some people can feel creativity and innovation are stifled

Enterprise Team
•	Cloud migration

Manual sign-offs
•	Gaps by having process broken out
•	Takes a very mature organization to have a push-button deployment to production

How would you design the development process from the ground up?
•	Idea 1
o	    Code using TDD
o	    Code gets pushed, runs through tests, continuously deployed
o	    Green/blue deployment pattern within the cloud
o	    Every environment has its own automated tests
o	    TDD, BDD
o	    CI/CD would alleviate the tradeoff (initial setup can take lots of time, CI/CD reduces that 
        time)
•	Idea 2
o	    OpenSource model
o	    Let teams succeed and fail on their own
o	    Trust the teams – they will iteratively change for the better as they realize what works and 
        what doesn't work
•	Idea 3
o	    Ease of use
o	    Visibility around consequences of your coding actions
	        Initial dev environment  knowing if something is successful in production
	        Use of features by customer

Source Control
•	Git, GitLab
•	TFS
•	Code Reviews

Training
•	Pair programming
•	Mob programming
•	Ping-pong development

Behavior Driven Development
•	Writing tests aligned with what the business would actually do with the product, rather than unit 
    tests
•	Can have a mix of BDD and TDD (test driven development)
•	BDD is more business-driven

Importance of Cross-Functionality – silos can enable the "they'll catch it downstream" mentality

Ferrix Hovi - Head of DevOps - Siili22:10:13

I could offer a pattern: have an annoyingly good set of smoke tests that will interrupt the flow constantly because it is good at proving something is not right at all and points towards a few teams who need to investigate. That will be an effective gate if the brokenness is unacceptable. People will start building around those tests and get used to having the safety.

👆 1
Ferrix Hovi - Head of DevOps - Siili22:10:12

We had 17 smoke tests for an anti-malware solution in 2009 and about 1000 in 2011

Ferrix Hovi - Head of DevOps - Siili23:10:20

About 200 people in the program.

Nick Jenkins (Director, Mech Rock DevOps, Perth, Oz)00:10:24

Yay for BDD. It's a core of what we do with clients. Anyone use it with infrastructure aka BDI ?

Vaidik Kapoor (Speaker) - Technology Consultant06:10:15

seems like an engaging discussion that i missed