Lifecycle of a microservices application - Iasi, Levi9 meetup - 28-6-2017
•Descargar como PPTX, PDF•
0 recomendaciones•333 vistas
A talk delivered at a Levi9 meetup in Iasi. Ideas and important points to successfully deliver a microservices application are discussed.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Lifecycle of a microservices application - Iasi, Levi9 meetup - 28-6-2017
Similar a Lifecycle of a microservices application - Iasi, Levi9 meetup - 28-6-2017 (20)
Más de Pavel Chunyayev
Más de Pavel Chunyayev (8)
Último
Último (20)
Lifecycle of a microservices application - Iasi, Levi9 meetup - 28-6-2017
- 1. @PavelChunyayev Lifecycle of a microservices application What does it take to develop and run a micro service by Pavel Chunyayev, 29-6-2017 Levi Nine, Iasi
- 2. @PavelChunyayev In theory, there is no difference between theory and practice.
- 3. @PavelChunyayev In theory, there is no difference between theory and practice. But, in practice, there is. Jan L.A. van de Snepscheut and/or Yogi Berra
- 4. @PavelChunyayev It may be all right in practice, but it will never work in theory. Warren Buffett
- 5. @PavelChunyayev What we will cover today • Lifecycles • Process for application delivery • Best team to develop a microservice • Lean ideas
- 6. @PavelChunyayev Pavel Chunyayev • Already three years in the Netherlands • Background in IT operations, Ukraine, Estonia • Help software development to achieve business goals • In company with 900 smart engineers
- 9. @PavelChunyayev Lifecycle of a feature Plan Code Build Test Release OperateEnvision
- 13. @PavelChunyayev Build quality in Shared responsibility
- 16. @PavelChunyayev Continuous Delivery Plan Code Build Test Release OperateEnvision
- 17. @PavelChunyayev Continuous Delivery Plan Code Build Test Release OperateEnvision
- 18. @PavelChunyayev
- 19. @PavelChunyayev
- 20. @PavelChunyayev
- 21. @PavelChunyayev
- 22. @PavelChunyayev
- 23. @PavelChunyayev
- 24. @PavelChunyayev “Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.” W. Edwards Deming Fourteen Points for the Transformation of Management
- 25. @PavelChunyayev Build quality in • Testing is not just presence or absence of defects • Testing is not a separate process • Test should not just raise the cost of maintenance • Stop thinking about functional testing only • Test early, move tests to the left • Quality goal need to be established early in the development process • Automated testing – part of Definition of Done • TDD
- 27. @PavelChunyayev
- 28. @PavelChunyayev Testing is a shared responsibility
- 29. @PavelChunyayev Updating an API contract Crucial monent in an application lifecycle
- 30. @PavelChunyayev
- 37. @PavelChunyayev High performing team – Purpose and Autonomy • Does the mission/purpose of my company make me feel like my work is important? • Does my supervisor, or someone at work, seem to care about me as a person? • Do I understand how my everyday decision helps mission/purpose of my company? • Do I know what is expected of me at work? • At work, do my opinions seem to count?
- 38. @PavelChunyayev High performing team - Mastery • Do I have the materials & equipment I need to do my work right? • At work, do I have the opportunity to do what I do best every day? • Is there someone at work who cares about my development? • Are my co-workers committed to doing quality work? • In the last 6 months, have I talked with someone about my development? • At work, have I had opportunities to learn and grow?
- 39. @PavelChunyayev DoI have the opportunity to do what I do best every day?
- 40. @PavelChunyayev People are companies’ best asset
- 41. @PavelChunyayev “Developing people and the system so that together they are capable of achieving successful results is the point.” Mary and Tom Poppendieck
- 43. @PavelChunyayev Lean software development - Principles • Eliminate waste • Amplify learning • Decide as late as possible • Deliver as fast as possible • Empower the team • Build quality in • Optimize for the whole
- 44. @PavelChunyayev Waste • Partially done work (Starting more than finishing) • Extra processes (Bureaucracy) • Extra features (Unnecessary code) • Task switching (Changing requirements and priorities) • Waiting (Delays in the development process) • Motion • Defects (Quality issues, rework)
- 45. @PavelChunyayev Amplify learning • Pair programming • Code reviews • Documentation • Wiki • Commented code • Knowledge sharing sessions • Training
- 46. @PavelChunyayev Decide as late as possible • For decisions that are irreversible or impractical to reverse • Keep the options for as long as possible • You will know a lot more by the time the decision needs to be made • Too early and you are limited by the choice you could have made without enough information
- 47. @PavelChunyayev Deliver as fast as possible • Continuous Delivery • DevOps • Agile methodologies • Shared responsibility
- 48. @PavelChunyayev Empower the people • Give responsibility to make decisions about their work
- 49. @PavelChunyayev Build quality in • Andon – stop the line • Pair programming • Test driven development • Constant feedback • Minimize handovers (time between stages) • Continuous integration • Automation
- 50. @PavelChunyayev Optimize for the whole • Optimize for the whole, not specific departments or teams • E2e process with focus on customer needs • Prefer product orientation vs project orientation • Focus on quality and innovation, not on quick execution
- 51. @PavelChunyayev Problems of Lean • Cargo cult • Focus on tools, not on the philosophy and culture • Decide on the solution without understanding true problem
- 52. @PavelChunyayev Lean software development - Principles • Eliminate waste • Amplify learning • Decide as late as possible • Deliver as fast as possible • Empower the team • Build quality in • Optimize for the whole
- 53. @PavelChunyayev
- 54. @PavelChunyayev +31 6 2117 5817 pavel@levi9.com Common goal Developer Product Owner Stakeholder
Notas del editor
- .
- .
- .
- .
- .
- .
- .
- .
- .
- Plan Create a plan, define steps, predict results of the change Do Execute the plan on a small scale or in a test environment. Check Examine the results. Decide whether to continue or try again. Act Implement the change on the broader scale or further.
- .
- .
- .
- .
- .
- Specific part
- Three different profiles, Must be one. You build it, you run it.
- Reproducible and repeatable process (including testing). Keeping the product releasable
- .
- Run over and over again.
- .
- No DTAP. Immutable (testing framework?) TTL Framework to allow restart - select arbitrary test
- BTR on every level Separation of testing. Move tests left.
- Process perspective, Don’t wait till the end of production, do it as soon as possible handovers are bad
- Shared responsibility.
- Building the thing right Building the right thing
- Adaptive systems Positive Negative Feedback from testing, from production, feature validation
- One common goal. Collaboration between business, development, QA and operations. Not fot nothing it’s called ‘cross functional’ team There’s no place for manual work anymore.
- .
- .
- * Semantic or not semantic * API versioning - public or also internal? * Transition between versions – testing different versions * Running several versions together
- * Semantic or not semantic * API versioning - public or also internal? * Transition between versioning – testing different versions * Running several versions together
- * Semantic or not semantic * API versioning - public or also internal? * Transition between versioning – testing different versions * Running several versions together
- * Semantic or not semantic * API versioning - public or also internal? * Transition between versioning – testing different versions * Running several versions together
- * Semantic or not semantic * API versioning - public or also internal? * Transition between versioning – testing different versions * Running several versions together
- No tester No admin
- .
- .
- .
- .
- .
- Mary and Tom Poppendieck
- .
- .
- .
- . But not too late :)
- .
- .
- .
- More sloppy code because of urgency Bigger utilization of departments (QA)
- .
- .
- .
- .