• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
How fast can you onboard a new team member with VAGRANT ?
 

How fast can you onboard a new team member with VAGRANT ?

on

  • 277 views

As the number of developers on a project, the number of projects in an Organization, or the complexity of a single project increases, it also becomes increasingly difficult to keep our development ...

As the number of developers on a project, the number of projects in an Organization, or the complexity of a single project increases, it also becomes increasingly difficult to keep our development environments operational. From changing dependencies and differing server versions to running completely different operating systems specially windows machines of FrontEnd team, keeping the process of getting a running development environment sane and repeatable is non-trivial.
Getting the development environments identically setup can be a huge undertaking. On top of that, some people use Mac while others Use Linux or Windows. Before you know it, developers will be throwing computers through walls exhausted from constantly configuring and configuring. Windows machine devs yelling WTF is this Imagemagick , people using Mac asking which is better macports vs homebrew vs fink.

Vagrant solves all of this by introducing a common configuration format and workflow for describing and building development environments repeatably across Mac OS X, Windows, or Linux.

Statistics

Views

Total Views
277
Views on SlideShare
235
Embed Views
42

Actions

Likes
1
Downloads
0
Comments
0

4 Embeds 42

https://hasgeek.tv 30
https://twitter.com 8
https://www.linkedin.com 3
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    How fast can you onboard a new team member with VAGRANT ? How fast can you onboard a new team member with VAGRANT ? Presentation Transcript

    • Welcome to The Perfect World. How fast you can onboard a new team member
    • • A Weboniser and Rubyist • A Blogger(vparihar01.github.com) • A Geek • DevOps Guy • An Aspiring Tech Innovator • Tweet with @vparihar And Me!
    • Agenda ● Why You Are Doing What You Are Doing? ● What’s Wrong With It? ● What Are My Options ? ● The Future You Ask ? ● Limitations or Known Gotchas? ● Our Take
    • ● You have to develop an awesome application. ● The app is huge, challenging and most importantly cool ● Team of 10 - 15 includes Backend/Frontend Devs, Quality Analysts etc., ● You Need Rails , Node.js , Imagemagick , FFmpeg, Ruby Gems , MYSQL and even MongoDB. 1. Typical Project Scenario Why You Are Doing… What You are Doing...
    • 2. Setting up the development environment. Why You Are Doing… What You are Doing... ● Ideally you’re going to want all 15 people on the team working on this app to have identical development environments. ● You provide a readme file to each of the developer’s to start setting up their machines. ● Even on the same team people can have different machine setups and tool choices (Mac, Linux , Windows ). ● Problem ?
    • Even with a provide full fledge documentation for how to setup the development environments can be a huge task. eg: Windows machine yelling WTF is this Imagemagick , people using Mac asking which is better macports vs homebrew vs fink. What’s wrong with It?
    • ● How long does it usually take for a new team member to be ready to work on your team ? ● What you do now ? Give him/her the again a readme doc ? ● It might take a day or two or worse existing team members time is also wasted in setting up the machine for him/her. ● Problem again ? 1. New team member on-boarding What’s wrong with It?
    • 2. Working on Multiple Projects What’s wrong with It? ● Developers and QA working on different projects , require different versions of ruby , libraries , gems etc., installed on their machine. ● How do you solve that ?
    • ● Wait? Don’t we do that already? Isn’t that what RVM, NPM,MAVEN and BUNDLER are for? ● They do great things for keeping Ruby versions separate and project gems in isolation. ● But they do nothing to help with application dependencies like Oracle, Passenger,Apache ,ImageMagick, Qt(for WebKit) etc., etc ● Problem Again ? What’s Wrong With It?
    • Expression of a dev, when asked to work on a New Project.
    • Who has not heard this sentence? Mostly during bug fixing , It's so common that each dev either it is FrontEnd / Application Developer they keep saying and yelling at you
    • What Are My Options ? ● ● ● ● ● ●
    • “ C’mon, what is this, two thousand ten? It’s the freakin’ future, man. Instructions for humans are nowhere near as good as instructions for computers. Humans make mistakes, misunderstand, and are generally not as fast as computers when doing this kind of thing. We can tell the computer to do stuff on our behalf while we watch videos of adorable animals! ” -Riley What’s The Future You Ask ?
    • ● It solves a very huge problem of “works on my machine” by very common concept, that is creating your own private VMs(virtual machines) ● In simple words what I understood from being a DevOps is taking Snapshot of your instance or VM. What’s The Future You Ask ?
    • Those who don't know about Snapshot's, here are some quotes from Stackoverflow "Snapshots : An exact capture of what a volume looked like at a particular moment in time, including all it's data. You could have a volume, attach it to your instance, fill it up with stuff like Rails , Node.js, Imagemagick and FFmpeg(video conversion libraries), ruby gems MySQL etc, then snapshot it, but keep using it. What’s The Future You Ask ?
    • ● Using Vagrant we can build development environments repeatedly across Mac OS X, Windows, or Linux. ● A developer’s box kinda becomes this sketchy place where you just really want to wash your hands after using it. ● Vagrant provides a great way to keep all of that nicely contained, per project, and away from your precious development machine. What’s The Future You Ask ?
    • ● The cool thing about Vagrant is that you can create a full dev environment, with every tool/library required for development already installed and ready to use. ● Package this up (and the VM's configuration) into a single file that you can use as a template. ● You have one single file that you distribute to your other team member and everyone can then use the same environment in couple of minutes without any hustle :) to build and break. ● New team member on-boarding? No Problem now. What’s The Future You Ask ?
    • ● If you do it right, you can even leverage your provisioning information to provision your operational or test systems ● No more hunting down weird dependency problems or debugging. ● Push Vagrant to the limits, it supports the concept of multi-VMs By using multi-VM support. ● Single vagrant up command, bring up an entire stack of clustered nodes
    • ● Vagrant interacts with VirtualBox mmm…. It might be the problem. ● If you run the virtual network editor on Windows, the forwarded ports will suddenly stop working.. Happens sometimes :P ○ Run vagrant reload and things will begin working again. ● In some cases reported Vagrant is slow in Windows Machines…. ○ Just Enabling DNS proxy in NAT mode Limitations or Known Gotchas?
    • By choosing to use Vagrant, our projects and organization gain some immediate benefits: ● Every developer is now working within identical development environments. This eliminates a large portion of “works on my machine” issues. ● No more READMEs per project, or having to ask DevOps for help, or simply being lost. Our Take
    • ● Easy nuclear option ● When things go wrong, it can be really disheartening to reinstall your operating system. ● Instead put Vagrant to work ! ● Take a coffee break and you’ll be back up and running in no time. Our Take
    • ● The development environments are now sandboxed within virtual machines. ● First, the environments can replicated or run on any machine, it doesn't matter if it is Linux, Mac OS X, Windows etc. ● Multiple projects with potentially conflicting dependencies can even run side-by-side. Our Take
    • Thank You!