10 Exclusive Development Practice Every Developer Should Consider

These are the slides I presented at DevFest Istanbul 2019 Conference

Transcript

1. every developer should consider lemi orhan ergin 10 exclusive development practice
2. LEMi ORHAN ERGiN co-founder, Craftbase founder, Software Craftsmanship Turkey alumni, Sony, eBay, ACM, iyzico programming, since 2001 with love speakerdeck.com/lemiorhan @lemiorhan
3. Something is wrong in software development
4. we are not developers anymore, we are framework implementers
5. high coupling and low cohesion makes impossible to write tests
6. we are afraid of refactoring even with a comprehensive test suite
7. rework is inevitable even the development is already done
8. we write unit tests, but functionalities still fail
9. Start with a mono-repo Refactoring is the most common activity you do for an immature in-progress product. So do not drown in change sets among multi repos. Start with one, split if required in the future.
10. Clear ownership for each repo Possible to restrict access for each repo Lightweight repository, narrow clones Independent upgrade & versioning strategy Manage like open source applications Multi Repository System Cross repo changes and refactorings are painful Adds overhead if one team handles multiple repos Need to open multiple IDEs to write code Need to manage versions of many small libraries Need to pull changes on many repos
11. All about moving fast and getting things done Enables experimenting cross-project More relevant pull requests & commits Cannot restrict to access for specific projects Low flexibility of dependency upgrade Needs special tooling for building Usefulness of tags diminishes Mono Repository System Easier to navigate on sourcecode Unified versioning, one source of truth You don’t need to define version numbers Easy cross-project refactoring Update dependencies to latest overall No wasting time with multiple git commands Increase developer productivity Twi!er, Facebook, Google, Digital Ocean, Foursquare, Etsy, Shippable, Ravelin Who migrated from multi to mono repositories?
12. You can not do CI without using mono-repos Ivan Moore
13. You can not do CI without using mono-repos Ivan Moore B C A unit tests integration tests component tests contract tests external verifier contract stub tests functional tests
14. Demo Time: Special Tooling with Gradle
15. Microservice Microservice Microservice Microservice Microservice Microservice Mono Repository Microservice Microservice Microservice Microservice Microservice Microservice
16. Microservice Microservice Microservice Microservice Microservice Microservice Mono Repository Microservice Microservice Microservice Microservice Microservice Microservice Read-only Multi Repositories splitting
17. Microservice Microservice Microservice Microservice Microservice Microservice Mono Repository Microservice Microservice Microservice Microservice Microservice Microservice Read-only Multi Repositories packaging & deployment splitting
18. Demo Time: Sparse Checkout
19. Using microservices when you are not prepared
20. Start with monoliths If you have no experience with building microservices at production, it could be a nightmare if you jump into it. Microservices requires to have devops culture, agile mindset and a new paradigm for software development. So be pragmatic.
21. HELL DEPENDENCY OF MICROSERVICES
22. Focus on modularity If you cannot develop well-crafted monoliths, how can you be sure you can build well- crafted microservices? Make your architecture clean and modular by following related design patterns and principles. Make your monolith well-crafted first. Then if you need to scale, split it to microservices.
23. https://twitter.com/martinfowler/status/606096712969633794 Martin Fowler Author, speaker, and general loud mouth on Software Development. Works for ThoughtWorks. posted: the monolith-first strategy to building microservices (or not) Martin Fowler @martinfowler 4:54 PM · Jun 3, 2015
24. Image Credit: Benoit Hediard, https://medium.com/@benorama/the-evolution-of-software-architecture-bd6ea674c477
25. Image Credit: Benoit Hediard, https://medium.com/@benorama/the-evolution-of-software-architecture-bd6ea674c477
26. ports business adapters mysql adapter stripe adapter rest api web ui domain
27. ports adapters domain 3rd party apps command line soap calls admin gui batch jobs mobile apps other hexagons cache provider elastic search mail server database sms provider message queue other hexagons business mysql adapter stripe adapter rest api web ui
28. ports adapters notification payment billing order basket restaurant scheduling caching search mail account messaging stripe adapter rest api mysql adapter web ui domain business
29. Hexagons in practice
30. domain infra
33. Sebastian Daschner from his talk about “Design principles for the effective developer” at Devoxx Ukraine 2019
35. Let it shaped with Domain Driven Design
36. ports adapters notification payment billing order basket restaurant scheduling caching search mail account messaging stripe adapter rest api mysql adapter web ui domain business
38. a SEARCH
39. a c SEARCH PAYMENT
40. c a SEARCH PAYMENT ACCOUNT
41. Walking Skeleton First release delivers an extremely small, but functional, initial version of your system. Once the skeleton of the system is in place, we have various places where we can start fleshing out functionality - putting meat on the bones. from the book “Growing Object-Oriented Software, Guided by Test” Deploy to production early and often, even start from the first sprint Focus on integration tasks first Build CD pipeline from the first day
42. Release and deploy code to prod multiple times a day Trunk Based Development lets you release multiple times a day. But it is a long journey to complete. do you really need that?
43. Weekly Releases STEP-1 Multiple Releases in a Day STEP-3 Daily Releases STEP-2
44. Daily Releases STEP-2 Multiple Releases in a Day STEP-3 Using Git-Flow Everyone codes individually No/few tests, huge manual test cost CI server used for building packages Weekly releases at best Manual deployment to pre-prod Manual functionality testing Manual deployment to prod DoD: Developed & tested at local
45. Multiple Releases in a Day STEP-3 Master-Feature branching Active Pair programming Have a test suite CI server runs tests for validation Daily releases at best Pull requests for code review Automatic deployment to pre-prod Manual functionality testing Manual deployment to prod DoD: Deployed to pre-prod Using Git-Flow Everyone codes individually No/few tests, huge manual test cost CI server used for building packages Weekly releases at best Manual deployment to pre-prod Manual functionality testing Manual deployment to prod DoD: Developed & tested at local
46. No branches, just master Feature flags Active Mob programming Have a elegant test suite Multiple releases per day at best No pull requests Each commit is deployable On-demand env. at each merge Automatic deployment to pre-prod Automatic acceptance testing Manual deployment to prod DoD: Deployed to prod Master-Feature branching Active Pair programming Have a test suite CI server runs tests for validation Daily releases at best Pull requests for code review Automatic deployment to pre-prod Manual functionality testing Manual deployment to prod DoD: Deployed to pre-prod Using Git-Flow Everyone codes individually No/few tests, huge manual test cost CI server used for building packages Weekly releases at best Manual deployment to pre-prod Manual functionality testing Manual deployment to prod DoD: Developed & tested at local trunk based development
47. If you want to go fast, go African Proverb If you want to go far go alone together
48. If you want to go fast, go Software Development Proverb If you want to go far go with pair with mob
49. One driver, many navigators Switch the keyboard regularly At least half a day in every week Mob Programming
50. 1. Start with mono-repository 2. Mono-repo splitting for easy CD pipeline 3. Advanced tooling with Gradle 4. Sparse-checkout for dealing with fewer files 5. Start with a monolith 6. Hexagonal architecture for modular monoliths 7. Mob programming 8. Trunk based development 9. Deploy to production from the first sprint 10. Release and deploy to production multiple times a day
51. @craftbaseio craftbase.io LEMi ORHAN ERGiN @lemiorhan