interaction is important to determine how to move forward 3. Versioning strategies 4. Deployment strategies 5. Implementing changes in our Microservice
and Scrum Masters Business Stakeholders Architects, Leads and Developers Quality Assurance Engineers Release Engineers DBAs IT Operations Development Stakeholders User
problems Software that add value New features and fast Incremental features Frequent changes (Continuous Change) Business development and continuity Sponsors / Costumers Product Owner / Project Manager Coaches and Scrum Masters Business Stakeholders Sponsors / Customers Product Owner / Project Manager Coaches and Scrum Masters Business Stakeholders
intends to break this collision with communication, empathy and collaboration improvement, along with useful technical practices, principally automation New features Corrections and improvements Optimizations Stability Security Troubleshooting Operations Devs
make changes to software quickly to integrate new features Software should be developed in order to integrate changes, instead of simply passing the tests Requires: • Use of adequate design patterns • Automation of the build process • Testing in different environments/levels • Fast functionality validation • Regression prevention • Quality measurement
with application development • Easy target to blame • Lack of traceability of databases changes (changes history) • Manual database processes prevent CI and CD
• $21.5 billion traded daily • $365M cash & equivalents ----- • NYSE launches Retail Liquidity Program on August 1, 2012, an automated routing system for equity orders • Group updates software to comply and repurpose 8-year old feature flag
of Knight’s technicians did not copy the new code to one of the eight SMARs computer servers.” SEC Filing | Release No. 70694 | October 16, 2013 ( http://tinyurl.com/Devops-Knightmare )
retail “parent-orders” • 7 servers processing “child-orders” correctly. • 8th server using the old feature flag code failed to recognize parent-orders were fulfilled. • 8th server sent cumulative child.-orders in rapid succession.
to react • Knight uninstalled the correct SMARS code from the seven servers where it had been deployed correctly • 9:30 AM to 10:15 • 4 million executions in 154 stocks • 357 million shares
at every change Features: A connection to a version control repository A build script A feedback mechanism A process for integrating the source code changes
project in VSTS • Create a repository for a Microservice, with in memory data • Implement the microservice using TDD • Create a basic build job for our microservice in VSTS • Se this whole setup run
Lack of traceability of database changes (changes history) Manual databases processes prevent the CI and CD utilization Lack of testability Database setup time for new environments Bugs in production
of response to change Keep a versioned “history” of database states and changes Reliability of the release process Increase release frequency though repeatability of processes Reduce time spent fixing bugs - automated tests Remove/reduce human intervention in the release process
database state Your source of truth is how the database should be Migrations based solutions Script represents a migration Migration represents how to transition to the next database version Your source of truth is how the database should change
database migration tool Flyway command-line enabled Simplicity: easy to setup, no need to install Zero dependencies (java + jdbc) Scripts are written in SQL
baseline, repair Metadata table: Used to track the state of the database If the database is empty, flyway won’t find it and will create it Flyway scans the migrations directory and check migrations against the metadata table Migrations are sorted based on their version number and applied in order
development Database • Add test project in Code • Implement database features in our microservice • Test • Add steps in our build system to support this • Deploy changes
enhancements • products need to move towards customer’s real needs • social and economic context affects how business is done Software NEEDS to change to enable this!
one component should NOT break all the others! Unfortunately, this is not always possible • more than one app consumes a service • more than one app consumes a database • binary data contracts (dlls) need to be updated everywhere • environment variables and changes affect program’s expected behaviour • lack of tests brings uncertainty to change outcome Many of these are anti-patterns!
communicated • Risk of change needs to be analysed • Effects need to be listed to prepare for possible problems and avoid fire- fighting • Teams need to announce how changes will impact existing processes and work. • Teams need to determine if the change is done in a single step or in multiple iterations.
a specific state • Collaborating components can assert their validity based on versions ◦ component A requires B version X or higher • Semantic versioning gives meaning to number ◦ prefer SemVer • Automate versioning as much as possible ◦ tooling and commit messages can be enough to indicate the type of change • Important part of a CI pipeline - end result of a build is a specific version of an
• Semantics matter ◦ minors and patches mean clients shouldn’t have to change anything, only update ◦ Majors are breaking so clients need to take some maintenance and realignment action • It’s also automatic documentation
(traffic volume, working hours, SLAs) • Single Server or service ◦ Stop service, upgrade, restart • Multiple Servers ◦ Stop service, upgrade, restart ◦ Blue-Green deployment ◦ Canary Deployment Whatever the scenario, automation is key
mutable. It’s super hard to rollback! ◦ How do you rollback changes that delete a column of data? • Application is typically immutable. It’s way easier to rollback ◦ Just need the database schema to be compatible This means that we typically need to make changes in multiple steps to avoid breaking the service. Schema should valid for backward compatible to at least 1 version of the application. Marking things as deprecated can / should make a difference.
deliver it Communication framework for change management You can not stop change, but you can control it Perspectives Need for speed (time-to- market) (management people) Need for control (error control) (operations people)
eduardopiairo
emiki
ham0215
kniino
pingcap0315
coconala_engineer
ks91
naitosatoshi
tebiki
yuyatakeyama
kaz1437
ch1aki
foursue
tammyeverts
bermonpainter
jrom
eitanlees
brianwarren
62gerente
mza
danielanewman
marcduiker
tenderlove
carmenintech
keithpitt
