Ruby Floripa 2019 - Why your company should have a Developer's Kit and how to build one

Today modern application can be composed of multiple pieces that is not always easy to fit together. From the majestic monolith to the micro-service based architecture, there is also a good chance you depend on multiple daemons with a pleteora of configuration parameters that needs be defined in harmony so you can run a fully capable development environment.

While some approaches like docker composer may be useful to some users, you are making a tradeoff of performance and convenience, by removing the ability to run things natively. You are also making harder for any more advanced debugging techniques on a lower level of your stack.

In this talk I will show you how you can build a Developer's Toolkit that compromises nothing: performance, convenience still gives you the ability to do system-level debugging, without any docker required.

Transcript

2. @brodock Gabriel Mazetto
4. Why your company should have a Developer’s Toolkit and how to build one
5. This talk is programming language agnostic
6. I will focus more on the Why and less on the How…
 
 But you will learn enough to be able to do it yourself at the end, trust me.
7. Let’s start talking about why you should do it…
10. All that time invested (wasted) solving programming challenges online were finally rewarded!
12. Now you are in and you are part of the team!
15. But instead of something simple and straightforward…
17. Yes, your new company uses Cloud and SaaS for everything…
22. Let’s switch roles a little bit… You are now wearing the Tech-Lead Hat
26. Have you ever thought of how much it cost to onboard a new developer?
27. Salary WorkDaysInAMonth * DaysOnboarding Salary 21 * 10
28. Let’s look at some Salary data on Glassdoor…
32. Salary 21 * 10 6500 21 * 10 = 3905,23
33. So let’s talk about how to do it…
34. Here are a few principles to guide you…
35. Principles:
 
 1. minimal effort to get started
36. Principles:
 
 2. good enough defaults
37. Principles:
 
 3. expose the internals and make it easy to hack
38. Principles:
 
 4. automate/scriptize as much as possible
39. Principles:
 
 5. be as flexible as possible
41. It hides complexity, but it doesn’t remove it
42. Packaging new software is not easy…
43. You are always running in “production mode” 
 by default
45. # create your own postgresql data per application mkdir postgres initdb --locale=C -E utf-8 postgres/data # run postgresql postgresql -D /path/to/your/postgres/data \ -k /path/to/your/postgres -h 127.0.0.1
46. # create your own redis server per application mkdir redis cd redis && wget https://raw.githubusercontent.com/antirez/redis/5.0/ redis.conf # run redis server redis-server /path/to/redis/redis.conf
47. How to package and distribute?
48. # Simple Procfile redis: redis-server redis/redis.conf postgresql: postgresql -D pg/data -k pg -h 127.0.0.1 # Execute with `foreman start`
50. Here are some other useful tools you can use
51. Makefiles
52. Rules and Dependencies
53. .NOTPARALLEL: 
 all: install configure install: echo "Use any shell command here." echo "Syntax require we ident with TABs" apt-get install git -y configure: git-config --global user.name "Gabriel Mazetto" git-config --global user.email "gabriel@gitlab.com"
54. Custom variables
55. # Local variables git_name: 'Gabriel Mazetto' git_email: 'gabriel@gitlab.com' 
 # Exported variables RAILS_ENV: 'test'
 
 .NOTPARALLEL: 
 all: install configure install: @echo "Use any shell command here." @echo "Syntax require we ident with TABs" apt-get install git -y configure: git-config --global user.name "${git_name}" git-config --global user.email "${git_email}"
56. Interfearence Steps
57. .NOTPARALLEL: 
 all: .git-config .git-config: @echo "this will be executed only once, or whenever you remove the file" git-config --global user.name "Gabriel Mazetto" git-config --global user.email "gabriel@gitlab.com" clean: rm .git-config
58. .NOTPARALLEL: 
 all: .git-config .git-config: @echo "this will be executed only once, or whenever you remove the file" git-config --global user.name "Gabriel Mazetto" git-config --global user.email "gabriel@gitlab.com" # make sure clean is not matched to an existing file on disk .PHONY: clean clean: rm .git-config
59. Some other uses for a Makefile…
60. Rakefiles
61. desc 'Install all dependencies' task :install do puts "Use any shell command here." puts "Syntax require we ident with TABs" system "apt-get install git -y" end desc 'Configure everything' task :configure do system 'git-config --global user.name "Gabriel Mazetto" system 'git-config --global user.email "gabriel@gitlab.com"' end task :default => [:install, :configure]
62. file '.git-config' do system 'git-config --global user.name "Gabriel Mazetto"' end directory 'gitlab' do system 'git clone https://gitlab.com/gitlab-org/gitlab-ce .' end task :clone_to, [:path] do system "git clone https://gitlab.com/gitlab-org/gitlab-ce #{@path}" end
63. How we do at
64. GitLab depends on multiple applications with specific configurations
65. Production:
 Omnibus setup,
 
 Kubernetes Helm Chart
67. GitLab Development Kit
 (GDK)
68. # Read the Getting Started here: # https://gitlab.com/gitlab-org/gitlab-development-kit # install GDK rubygem gem install gitlab-development-kit # initialize a new contained environment gdk init gitlab # will clone and setup everything cd gitlab && gdk install # to execute GitLab on your local machine gdk run # to regenerate configuration files gdk reconfigure # to update all dependent repositories gdk update
69. Questions?
70. Thanks