Scaling the Build Process at Home Depot
Speaker: Matt McKenny & Jeff Millimek

• Previously had regimented build process – had to be Java on Tomcat with Eclipse.
• Now can use almost anything.
• Shift to culture of expermentation
• Focus on speed and feedback
• Opinionated about not having an opinion

Tools

• Need to change tools/stack as learn
• Used to have one Enterprise Jenkins for everyone. People wanted different plugins so became special snowflakes.
• With Cloud can get new Concourse CI cloud server in 8 minutes vs ticket and waiting
• Provide example pipelines – search and replace example repo with team one and good to go [isn’t this a lot of repetition?]
• Slack – easier to discuss with remote people – communication and info sharing. Worked with managers to make sure everyone had a certain amount of time to spend on slack.
• In person, use stickies

For publicly traded companies

• track actuals of labor or average over a period of time
• SOX – move away from waterfall tollgate and build new change management approach with pipelines

Lessons learned

• No single owner of how do CI. Need to include developers. Everyone be part of the conversation. Less likely for everyone to standup own thing.
• At scale, individual choices harder. Allow for common path and then iterate on snowflakes.
• Free/cheap on demand servers
• Secure social collaboration
• Work with teams who want to change
• 300+ concourse servers. Also have Jenkins, Drone, TeamCity

State or Events?
Speaker: Kenny Bastani & Jakub Pilimon

Live coding

• Showed Groovy code using Spock for tests. [didn’t actually mention it was Spock, but easy enough to recognize]
• Wrote tests first for a CreditCard object [nice advantage of tests in Groovy. The methods don’t need to exist and you don’t get red errors as you type so not tempted to write the methods]
• The CreditCard implementation was logical with instance variables.
• Noted that the method to assign the limit is a command with an invariant.
• CQS – command query segregation

Refactoring to events

• Create domain events
  • For name, pick a past tense description of what it does. For example “limitAssigned”. Used same name for method and domain event object (which is passed to method as parameter).
  • Add timestamp to event so know order. That way can determine current state of object.
  • Also need former instance variables (limit) and parameters (amount) as attributes of the new domain event.
  • Similarly refactored to have withdraw(CardWithdraw c) and repay(CardRepay c)
• Keep track of changes and store
  • Dirty context – when change object but haven’t saved yet.
  • Add instance variable for list of domain events. This keeps track of the pending/dirty events
• Create Repository object
  • instance variable with map of unique credit card ids to a list of domain events
  • method to save to map
  • method to load credit cards by replaying all events. Used left fold. “It’s so fancy that Java 8 doesn’t support it out of the box”. Used javaslang.collection.List API to get it.
• Update CreditCard three handler methods to return a references to “this” so can chain
• Added Kafka so could store events (via Topics)
  • Added spring-kafka and kafka-streams to pom
  • Created config class with @EnableKafka
  • Update save method to use Kafka class
• Then switched to Kafka streams
  • @EnableKafkaStreams
  • Created new bean for stream configuration
  • return KTable – key table – aggregate of events from object
• Create controller
  • method to get list of credit cards
• Created scheduler for testing a bunch of credit card transactions

[this was a full house; I barely got a seat. Pivotal handed that well. They found all the empty seats and directed people do them. Even so, there are a good number of people in the back.]

Crossing the CI/CD/DevOps Chasm
Speaker: Miranda LeBlanc (Liberty Mutual)

Goals

• Cloud native enterprise – continuous delivery of valuable software
• Embrace DevOps – culture of trust, safety and confidence
• Agile
• Microservices architecture

Working with services/teams

• Operate in an open source fashion
• Can submit pull requests to other teams
• Liberty CloudForge – internal tooling team to support business facing teams.

Security

• Need to protect medical and financial data
• Build safety, security and compliance into pipeline

Goals vs Reality

• Developers focused on own team/business units.
• Not ready to do open source like development.
• Not ready to look at chasm let alone cross it.

Approach

• Started experimenting with tools and standing up CI.
• Then progressed to static analysis/code review.
• Then DevOps and automated deployments
• Then PaaS
• Then to Prod in 5 minutes

MVP

• Focus on MVP on every feature/story
• Minimal feature is a proof of concept
• Want MVP that will delight customers

Challenges

• Removing features that aren’t delivering value (or not delivering value anymore)
• Growth – going from 10-50 people. Everyone can’t know everything.

Lessons Learned

• CI/CD requires real software engineering skill – learning Maven/Gradle, automated testing, etc.
• Define key metrics up front and use them – ex: released a bug to prod because focused on unit test coverage
• Culture and behaviors matter – ex: get whole team on board with new wait of thinking. Want to avoid asking what date trying to hit. Roadmaps are for conversations not commitments.