First Pull Request - Sergio Ocon - ManageIQ Design Summit 2016
Download as PPTX, PDF1 like759 views
This document summarizes the onboarding process for a new developer joining the ManageIQ team. It includes setting up their development environment, learning key technologies like Ruby, Rails, Git and testing frameworks. It discusses best practices for creating pull requests, including writing tests, breaking work into logical commits, and getting feedback from the community on Github or Gitter. It also covers migrations and ensuring backwards compatibility when making database changes. The document encourages asking for help from the wider ManageIQ community.
![Github
We tried several solutions
We could not make them work for us
WIP / Assignments
You have a tag
[WIP] And a header
MIQ-bot can help
You don’t need access to the repo to change things](https://image.slidesharecdn.com/125manageiqsummit2016-makingyourfirstpullrequest-160616194559/85/First-Pull-Request-Sergio-Ocon-ManageIQ-Design-Summit-2016-8-320.jpg)
First Pull Request - Sergio Ocon - ManageIQ Design Summit 2016
- 1. From Zero to Merged Or how we made it happen with some help ManageIQ Design Summit June 2016
- 2. Agenda Your excited first day Our development Environment On pull requests Tests Migrations Asking for help
- 3. First day on the job TO DO LIST: Learn Ruby Rails Gems Haml RSPEC Git Github Rubocop
- 4. I :heart: ruby It’s a long way ... get support. RUBY ON RAILS TUTORIAL (3RD ED.) Learn Web Development with Rails - Michael Hartl The Rails 4 Way - Fernandez Obie (Autor), Faustino Kevin (Autor)
- 6. Setting up your development environment Read the Developer Setup in ManageIQ Guides System packages Ruby & bundler Git & Github Rails environment up and running Minimum workers Console Update dependencies and migrating
- 7. Virtual environment RHEV (Ovirt) - So you can manage it with MIQ (*) MIQ - What else? - A reference Satellite - Configuration management - Content distribution IdM - Identity Management OpenShift - Friendly PaaS Ansible - Configuration management (*) Your source of data
- 8. Github We tried several solutions We could not make them work for us WIP / Assignments You have a tag [WIP] And a header MIQ-bot can help You don’t need access to the repo to change things
- 9. Gerrit We tried that too… Overkill Strange case of bleeding eyes Github code review was enough
- 10. CI / CD TESTING BEFORE PULL REQUESTS You can configure travis to run when you push in your fork (https://travis-ci.org/). Allows for easier review of your code before the PR Same automatic review that will happen for the PR.
- 12. On pull requests Just do it!
- 13. Creating the pull request # git checkount -b “my awesome feature” <CODE AS A GENTLEMAN> # git commit -a -m “Let’s make a useful description here” # git rebase <PULL-REQUEST>
- 14. Size matters Choose the one that applies: 1. Complete functionality (i.e. that big awesome pull request that creates a new chargeback, fixed the world and praises God at the same time) 2. Independent functionality (i.e. that big pull request that needs others) 3. Something that works (i.e. complete feature but only part of a use case) 4. A small pull request (i.e. nothing works here but it is fine) Does it have tests? Many? Is it commented? Is it documented? Are the commits showing a logical sequence?
- 15. Tests
- 16. Tests on your laptop Guidelines for Rspec http://betterspecs.org/ Rubocop http://batsov.com/rubocop/ Dedicate some time to learn them…. Because...
- 17. Why make a nice test?
- 18. Day 1 There is a new merge in code. Commits broken code the day before release that makes your code fail.
- 19. Day 2 You don’t know where the problem is You only see...
- 20. Day 2 You don’t know where the problem is You only see...
- 21. How to solve minimize that? Learn Rspec Test your code in every aspect with Rspec Happy path Not so happy path Edge cases That case that happens when somebody else changes his/yours/other’s code Make sure your code won’t fail in the future
- 22. Untested code is broken code Martin Aspeli Philipp von Weitershausen
- 23. Migrations
- 24. Backwards compatibility You need to migrate the model And test it But you need to migrate the data too (i.e. those ~2k VM) And test that, too! And it is possible that you want to go back And you should test that Have we talked about backporting? (we don’t) Even if you don’t
- 25. Asking for help (CC BY 2.0) https://www.flickr.com/photos/30793552@N04/6237765131/in/photostream/
- 26. Never give up
- 27. You’re not alone
- 28. talk.manageiq.org Expose your problem Ask the community
- 29. IRC I haven’t seen too much activity there… (so see next slide) #manageiq in freenode
- 30. Github There is a lot of interaction within pull-requests You can refer to @people And to #issues It is an iterative process
- 31. Gitter Active community with many channels: UI Chargeback Tenancy Providers Core Automate Containers Performance ...
- 32. ManageIQ Spain Team e-mail: alvaro.delaluz@neartechnologies.com github: @delaluzparra e-mail: aljesusg@gmail.com github: @aljesusg
- 33. ManageIQ Spain Team e-mail: Tamledric@gmail.com github: @tledesma e-mail: amaury.muro@gmail.com github: @amaurygonzalez
- 34. Thank you!