 Hi, everyone. Welcome back. Today we have Vivek Parihar from Webinize Lab. He's going to talk about how fast you can onboard a new member into your team, and the practices that they usually do with their team to do this is here. Hey guys, good afternoon. I think everybody is tummageful and feeling sleepy. So let's try to make yourself up for the next 20 minutes. I will be talking about welcome to the perfect world. Yeah, it is not a perfect world, but we try to make it a perfect world, and we try to make a virtual perfect world. So basically, I'm going to talk about how fast you can onboard a new team member, as well as how fast you can onboard a whole fully functioning team, and start doing development. So, yeah, and me, I'm a Webinizer. I work in a Webinize. I'm an AVP of engineering. I look over all DevOps, and basically I'm a Rubyist. I do programming Ruby, but love Java as well, and great love for infrastructure, because it's a challenge that you can really, every day, keep getting all these new challenge every time. And I do blog at this vparihar01.github.com, and if you want to connect with me, it's in my Twitter handle, at the right vparihar. So this is an agenda, like what you are doing. It's not related. It might be like a lot of you guys are not doing this, but yeah, I'm just going to address what we are doing in previous days, and what's wrong with that, and what are my options, and how we update, and what are the future that we ask from this particular tool that I choose, and how we update. And limitation, like a little bit of our limitation, we still have, as I told you, it's not a perfect world, but yeah, we try to make it as much as perfect. Second is what is my take on that particular methodology. So basically, let's take what we are doing, or what we are doing previously, or might be what you are doing right now. So let's talk about a little bit of this typical scenario. Let's say that you have to develop an application, an application that requires a lot of different applications. It might require different languages, and 10 to 15 people is working on that particular team. So the app is huge, Shellingen, and most importantly, it should work very smoothly. So everybody can work similarly. So I'm just taking an example, like some of the applications that we figured out, it might be a little bit hard to set up for each and every team member that might on board our team. So let's say that you are having, you have to have Rails, Node, ImageMagic, FMPAC, RubyGems, and MySQL, even MongoDB. So next thing, so what we want from our developers, we ask them to set up a developer environment. So what we do first, we give them some certain readme file in which we return how you can set up an environment, and we listed all these steps that they can follow. So ideally, you are going to want all 15 people on the team working on this app to have identical development environment, and you can provide a readme file that I told you. Even on the same team, people can have different, different operating system that could be Mac, Windows, and open to our Linux, whatever Linux system that we are using. So it could be a choice of a developer that developer is working on it. So this is a major problem that we deal each and every day because it could be a frontend, it could be your QA, it could be a developer who might want to work on Mac, or somebody wants to work on, comfortable with Windows, and somebody is comfortable with the Linux systems. So this is the problem. So what's wrong with this particular operating system is even if we provide a full flat documentation to each and every individual, like for a Windows, for an open to, and for a Mac as well, but everybody is not expert about their operating system. So we have to have somehow given some guidelines or steps so they can follow it. So like a lot of times we end up with this situation, Windows machine yelling, what is this image magic? So a lot of times we, I personally struggle to manage, like install this image magic on Windows, people using Mac asking which is better, like Mac port, Flink, and Homebrew. And so like a lot of people came to you and ask you, okay dude, I'm not a code, I'm a code, I'm not a like DevOps or I'm not a sysadmin. So you have to set this particular application system for me. I don't know how it's going to work for me. So what's wrong with it? Like let's say that somebody, like a new team member is onboarding. So what happened? Like what do we ask? First we given like first, like how, so the problem with this is like how long is going to take, how much time we need or how much time that person, that who is boarding on that particular team, that application that we are going to develop, how much time is going to take? We don't want to spend a huge amount of time for that particular team member to set up that development environment. So what do you know? Like give him like again a read me doc. So what the other people is following, it might take a day or two of us, like other team member have to help that person because that person don't know about the operating system. So it's again a problem. So for a new team member, it's again a problem because that person don't know about the application, that person don't know about your application stacks. So you have to have that person. Again, the second problem we came across a lot when we are working on multiple projects. Like a lot of you guys keep working on multiple projects. So what have been, what is the major problem? So the major problem is like we have to maintain our different, different versions of application stack. It could be a program, like it could be a Ruby, it could be a Magmatic, it could be a MySQL, a lot of things. So we have to have these things in our mind. So there is a way that we can solve it and a lot of programming language provide these things, how we can handle, how we can really version of our system. So in Ruby we have like, we have like RBM and we have Bundlara and NPM for node. And for me, even also we can use for Java to really install our dependencies as per required. But they do great things for keeping Ruby versions separate and project them since isolation, the same with other tools as well. But they do nothing to help with application dependence like Oracle, Presenger, Apache, ImageMagic, QT and ATC. So you might end up like, let's say you are working on some MySQL version and some other MySQL version is not working for your application, so what do you do? So that's again a problem. So when you ask that day, okay, you have to work on multiple projects, okay, so just swap to that project. But you have to keep your previous, like old school, or like old stack as it is. So the expression like, so you are telling me I need to install newer version of MySQL, Apache, Ruby and its dependency for this new project. And but I have to keep all these previous versions installed in my system. So it's very, very tricky because like if you mess up with like your development mind, you are messed up. You have to redo it again. So, and second one of the, like biggest problem that we face each and every day, hey dude, please work on my machine. Also a lot of time, it's working on my machine. So I'm not getting this error. So how you are getting this error? So please don't me, I am not able to replicate it. So that's like major problem with this, like we have to have all these components in our development right now should be identical. So there are a lot of options available in market and in open source community. So you can use configuration measurement tool, but it's still like if you are using configuration measurement tool, it might cut some of the, this admin or debof practice in hand. The person should have some hands on that. So there could be like the puppet, chef, vortex, joker and unstable and Vagrant. So personally we choose this Vagrant as a tool that we can distribute to each and every team member in our organization that can help a lot or that can help to set up a fast development environment. So why we don't let people to have this installation on their hand because we know that human can do error. Human can do like pseudo, RM minus RF and dot, it will delete each and everything. So these type of common problem can arise a lot of time and believe me, it's happened a lot. And a lot of people do like CH mode 777 dot and you're done, you're not able to boot a stem again. So we have to give these responses to machine because they know what they're doing. They follow this instruction as it is a 1000 time in the same manner they did in previous version. So like what is the future, like what is the future that Vagran is giving to us and what we really want from that particular Vagran tool is like it solves a very huge problem that works on my machine because a person no longer say that it's working on machine because the application environment that is on stage or a production or a different QA team have, it's all identical. So we can have the same development environment. In simple words, like what I understand from this particular like having this Vagran system or having these Vagran VM in my system, I can take a snapshot and give it to my team members. So what this snapshot means, what I understand from the snapshot, like it's like a clear picture of that particular instance, whatever the dependencies, whatever like and your data in your system, you can just take it as it is and you can distribute to the people as well without, without like, like you don't have to wait for that particular snapshot to, to hold your work. So using Vagran, we can build development environments repeatedly across any platform, any operating system. It could be a Mac. It could be a Windows or Linux. I don't mention about Solace because I didn't test it, so I cannot tell you about that. Developers box kind of becomes a sketchy place where you just go and do anything and just wash your hand. And it's, it's in, in your VM, it's not going to eat up your whole development system. Vagran provides a great way to keep all these nationally contained per project away from your previous development. So what are the machine it is, what are the machine that you're using, it should, it's, it's keep intact with all your, like, what are the dependencies that you're installing. It doesn't interfere with your development machine. You can have whatever, like, like, what, what, what are the mess you have to play, you can do it on your VM. So yeah, the cool thing about the Vagran is that you can create a full depth environment with every tool or library required for development already installed and ready to use. And you can start using it and then what you can do, you can distribute that particular environment to your team member as well. Pack it is up and to a single file that you can use it as a template. And then you can have one single find that you can distribute to a team member and everyone, everyone can use the same environment as it is. If the person know about how it is, okay, if the person know about it, if that person is not good enough to understand how this admin works, how they work first, they can really just follow up to a three command, you are done. Your system is working. So new team member onboarding is no problem now for us, particularly. So there are some limitations still, like, we have a lot of limitations still in place while using Vagran. I'm not sure about, like, Vagran, we are using VirtualBox, so Vagran actually interacts with VirtualBox. It might be the problem or it might not. But sometime it might be a problem because you have to install a new VirtualBox if it is creating a problem. Second, if you're running the Virtual Network Editor on Windows, the forward port will suddenly stop working. So it's not like a blocker, but it's sometime happens. Like, for that, what are you going to do? You have to just do a Vagran reload and everything starts working fine. That's all. In some cases, like, some people reported, like, when coming to this conference, like, somebody, like, comment on my talk, like, Vagran is not that good in Windows. Yeah, the performance is a little bit slow, but what are you going to do? There are a lot of methodologies that is available, that you can have in Windows. Like, you can just enable DNS proxy in NAT mode. So it give a, like, quite good performance in Windows as well. So there are problems, and we can solve it, but I cannot assure, like, it would solve each and everything like 100%. There might be a problem. So basically, like, while using this Vagran, so we have our own take on to use it and to adopt it as a development environment. So each and every developer, because we scale from 20 to 200 people in, like, a couple of years. So it's a very huge task for my DevOps team and my network, like, CIS admin team to really manage all these system as it is. So we have to have some solutions so we can really have this development environment set up very fast. It could be in minutes. It could be in, like, a couple of minutes. So we don't want our developers to give, like, waste their precious time on, like, setting up something that they don't have to. So by choosing to use Vagran, our projects and organization gain some immediate benefits that I'm going to list here. Like, every developer is now working with identical development environments. This eliminates the large portion of Vagran machine, and second and the biggest thing is, like, a lot of our front-end engineers is not able to set up, like, full stack-off for application. It might be your... One of these applications is interacting with Node because it's using a pass proxy. So using a pass proxy in Windows and asking a front-end developer to set up is quite insane because they don't able to understand. They might have a mess up their Windows machine. So from this, what we can do, we can give them, like, this particular template what we are using. They have to just do a Vagran up, and they are done. They can do their own development on this development machine, and what are the dependencies they have to run? The Vagran VM can run on it. No more readme, parse project, or having to ask DevOps for help, or simply being blocks. So a lot of time, we just copy paste from Stack Overflow or some blocks, and now, okay, it might work. It might work. But in my MacBook, when I'm selling an image magic, it's a nightmare. Somebody told us, okay, use Homebrew. Home, use Think. So I end up installing each and every of these, like, tools to make image magic working, but it's quite hard. So, like, it's a nuclear op, like, so we can divide all these problems in separate, separate sections, so we can have, like, different, different VMs or different, different project template, and can store it in one place if somebody wants to work on some very old, very, very old Stack application that require, like, very old, like, Ruby version, PHP version, whatever the versions they are using. We can make it in a template. We can store it somewhere if some, if any bug can occur in, like, some near future, we can ask our developer, okay, use this template and set up the environment, and you are done, and fix this bug. So it's very, very easy in that perspective. So we have, like, nuclear options. When things go wrong, it can be really deciding to restore your each and every dependency that is available in your system. It might lost your SSH keys, it might lost your each and every configuration that you did in your development machine. So it's nice to have something, and it's nice to just, like, ask Vagrant to handle this for us, and we can take a coffee bake or, like, whatever, like, we can, whenever we came back, our VM is running back. Up. So the development environments are now sandboxed with virtual machines, so that's a good part of it. So nobody, nobody can mess up with some different development environments or somebody else's environment. You are just doing, or you are just messing up your own VM. So it's your mess, you can clean it, you can, if you don't like it, you can just destroy that VM, and you can just really make, create a new VM out of it. For the environment can be replicated or run any machine, it doesn't matter if it is Linux, Mac, and Windows. That's, like, one of the biggest part. If one of our team member, one of us, like, DevOps guy in the team, just set up an environment, it's done, everybody can use it, apart, whatever, like, operating system you are using. So you have to just have some small, like, tools in your, like, in your machine, like Vagrant and Ruby, to stall it. That's all. So multiple projects with potentially conflicted dependents can even run side-by-side. The moment you want to run, like, on some great one, you can just update machine and can start working in. The moment you have to work on project two, you can just shut down the first VM and can start a second project VM. And that's done, you are done. Yeah, so thank you. That's all from my, like, so there are a lot of life from the VM, still have, like, a lot of problem regarding Windows. It might still have, like, a lot of problem regarding the performance, because what are the assets that is transferring from VM to your machine is a little bit slow, because we are using sync, like, Windows use sync with the, that is a parameter from virtual box. But if we can use NFS, it is very, very fast. You can get, like, good amount of performance, but setting with NFS on Windows is a little bit hard. You have to use open NFS that is available for Windows. Yeah, thank you. Any question? We have time for two questions. Can I go ahead? So my question is, like, all of the web dev projects that we have in Mozilla actually using Vagrant to, you know, like, onboard new contributors. But the problem I have seen there is that if the virtual box versions are different from the person who has created the Vagrant VM and the person who is using, especially if it is older, it's really messy to get things set up. So how much of a problem have you faced in getting versions to be the same among the team members that you have? So basically, like, as I told you, like, we have to just give them, like, okay, we are using this version and you're done, you have to just set up these two tools and then you can use this particular VM. So it's very easy to just mandate or have some documentation on it, whatever we are using, what are the practices that we are following across the organization. So there is no, like, heterogeneous conviction available in the organization. It should be, like, a same, a same concept that should, each and every development machine should use. Yeah, hi, this is Devashish. I have two questions. First question is, when you say Windows, how does it work? Suppose in our environment, we use Visual Studio. The requirement is every developer, when he gets onboarded, we have to have Visual Studio Ultimate installed in that particular development machine. So how do you manage that? That is first question. So that's, like, I have to answer, like, from start, so we can matter, like, after this talk, I can be, like, brief about it. Okay. So the question is, there are certain tools which, again, same example is Visual Studio. It asks for a license. So each, so how do you manage the licenses with this? So we didn't, like, have, like, have this type of problem because right now we are not doing any development regarding, like, Windows-related development. So still we didn't figure out, like, have these type of problems. But yeah, there are a lot of solutions that is available by Windows itself. So if you go to, like, Windows open source, they have, like, some separate background setup, and there are a lot of things that you can set up in a development virtual machine. Okay. Well, you can catch up and... Yeah, definitely. Okay. Thank you, guys.