Download as PDF, PPTX
![Danger
1. Run SwiftLint
2. Block if CHANGELOG wasn’t changed (Except [TRIVIAL])
3. Block if there aren’t tests (Except [TRIVIAL])
4. Warn about what was changed
5. danger_swiftinfo](https://image.slidesharecdn.com/avoidingreleaseanxietypdf-211221154929/85/Avoiding-Release-Anxiety-41-320.jpg)
Avoiding Release Anxiety
- 1. Avoiding Release Anxietyin iOS Bruno Rocha The information in this document is not confidential to the person to whom it is addressed, so feel free to disclose it to any other person. It may be reproduced in whole or in part, allowing you to disclose this information without the prior consent of the directors of iFood. It has been used as support material for an oral presentation and, therefore, it does not represent a complete record of the topics presented in the mentioned presentation. +
- 2.
- 3. Need to adda feature Can’t do it properly without refactoring everything Ignore the problem Breaks in production, pushes hotfix Codebase gets worse
- 4.
- 5.
- 7. Rapiddo’s Releases 🤖 🍎 ~1 criticalhotfix every 2 weeks 2 critical hotfixes in 2 years Covering critical flows with UI Tests
- 8. Block-based UI Testing Testingefficiently
- 12. Typesafe Mocks andProtocols Testing efficiently
- 19. Mocks != RealAPIs
- 20. Smoke Tests UI Teststhat run on real APIs, triggered by backend changes.
- 21. UI Testing Pro •CI works == User’s app works
- 22. Reduce margin oferror Avoiding Release Anxiety
- 27. 🚨 Buck is notfor beginners!
- 37. CI/CD Damage Control Reducemargin of error
- 39. CI Pipeline forPRs 1. Clone 2. Install Dependencies 3. make ci 4. — bundle exec danger 5. — gen_xcode 6. — test_components 7. — test_ifood 8. — test_ui 9. — run_ifood (just check if the app can be installed)
- 40.
- 41. Danger 1. Run SwiftLint 2.Block if CHANGELOG wasn’t changed (Except [TRIVIAL]) 3. Block if there aren’t tests (Except [TRIVIAL]) 4. Warn about what was changed 5. danger_swiftinfo
- 47. master ✅ 🚫 feature1 feature2 ✅✅ 🚫 CI/CD Damage Control
- 49.
- 50.
- 51.
- 52. Review exigency Too little Toomuch (Instant release anxiety) (Toxic) 🚫 🚫
- 53. Review Guidelines 1. Checkif it follows the project’s style 2. Check if it works (is clearly unit tested) 3. Don’t be a dick
- 54. 😡 😡 Value your team’srelationship over nitpicking non-critical details
- 55. Review Etiquette You shouldguard instead of if here. We could use guard instead of if here. Use guard instead of if here.
- 56. Review Etiquette Questions insteadof demands Do this. What do you think of this?
- 57. Review Etiquette: Beingreviewed 1. Explain why the change was needed 2. Understand the reviewer's perspective 3. Don’t merge if you’re not confident it works
- 58. What should bereviewed?
- 59.
- 60.
- 61. -Chan 1. Every componentis different 2. Changing squads has a learning curve 3. Code review becomes hard 4. “Legacy" code plagues the app Not having a Style Guide can mean:
- 62.
- 63. Style Guide Pros 1.All code feels it was written by you 2. Changing others’ code is easy 3. Code review is easier/faster
- 65.
- 66. Style Guide Topics CleanCode & Naming
- 67. Style Guide Topics DesiredUsage of Compiler Syntax Sugar
- 68. Style Guides areIncremental
- 69. 👨💻👩💻 👨💻👩💻 👨💻👩💻👨💻👩💻 👨💻👩💻 App ❓❓ 1⃣ 2⃣ 3⃣ 4⃣ 5⃣ 1⃣ 1⃣ 1⃣ 1⃣ 1⃣
- 70. “But I don’thave time!”
- 72. iFood with Xcode 1.CI taking over 20 minutes to run 2. Infinite xcodeproj conflicts 3. Xcode failing to build due to swiftc argument size 4. Multiple bugs in production as tests from the inner Monorepo modules aren’t checked in CI
- 73. iFood with Buck 1.Local/CI builds can take only a few seconds to run thanks to Buck HTTP Cache 2. Creating new Monorepo modules is just a matter of creating the folders 3. Little to no conflicts thanks to Buck project generation 4. The main targets run the tests from all modules thanks to project generation
- 75.
- 76.