every developer should consider lemi orhan ergin 10 exclusive development practice

LEMi ORHAN ERGiN co-founder, Craftbase founder, Software Craftsmanship Turkey alumni, Sony, eBay, ACM, iyzico programming, since 2001 with love speakerdeck.com/lemiorhan @lemiorhan

Something is wrong in software development

we are not developers anymore, we are framework implementers

high coupling and low cohesion makes impossible to write tests

we are afraid of refactoring even with a comprehensive test suite

rework is inevitable even the development is already done

we write unit tests, but functionalities still fail

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.

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

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?

You can not do CI without using mono-repos Ivan Moore

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

Demo Time: Special Tooling with Gradle

Microservice Microservice Microservice Microservice Microservice Microservice Mono Repository Microservice Microservice Microservice Microservice Microservice Microservice

Microservice Microservice Microservice Microservice Microservice Microservice Mono Repository Microservice Microservice Microservice Microservice Microservice Microservice Read-only Multi Repositories splitting

Microservice Microservice Microservice Microservice Microservice Microservice Mono Repository Microservice Microservice Microservice Microservice Microservice Microservice Read-only Multi Repositories packaging & deployment splitting

Demo Time: Sparse Checkout

Using microservices when you are not prepared

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.

HELL DEPENDENCY OF MICROSERVICES

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.

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

Image Credit: Benoit Hediard, https://medium.com/@benorama/the-evolution-of-software-architecture-bd6ea674c477

Image Credit: Benoit Hediard, https://medium.com/@benorama/the-evolution-of-software-architecture-bd6ea674c477

ports business adapters mysql adapter stripe adapter rest api web ui domain

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

ports adapters notification payment billing order basket restaurant scheduling caching search mail account messaging stripe adapter rest api mysql adapter web ui domain business

Hexagons in practice

domain infra

No content

No content

Sebastian Daschner from his talk about “Design principles for the effective developer” at Devoxx Ukraine 2019

No content

Let it shaped with Domain Driven Design

ports adapters notification payment billing order basket restaurant scheduling caching search mail account messaging stripe adapter rest api mysql adapter web ui domain business

No content

a SEARCH

a c SEARCH PAYMENT

c a SEARCH PAYMENT ACCOUNT

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

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?

Weekly Releases STEP-1 Multiple Releases in a Day STEP-3 Daily Releases STEP-2

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

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

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

If you want to go fast, go African Proverb If you want to go far go alone together

If you want to go fast, go Software Development Proverb If you want to go far go with pair with mob

One driver, many navigators Switch the keyboard regularly At least half a day in every week Mob Programming

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

@craftbaseio craftbase.io LEMi ORHAN ERGiN @lemiorhan