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.

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)

5. Our
development
environment
No-frills solution

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.

11. Taiga
https://taiga.io/

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!