Saturday, August 2, 2014

Article 2 - Setting up a development workstation - Part 1 - Power of Vagrant

This is the second article in the Enterprise Application development series, definitely coming after a long time, but I hope to continue this series more regularly now.

In this multipart series, I will cover
  • Using Vagrant to simplify the process of creating development environments, such as to overcome many challenges faced in enterprise development teams.
  • Configuring your Guest tools to work with Vagrant virtual development environment.
  • Setting up your IDE such that it looks cool and helps you spend extended hours coding (optional)
Some days back I blogged on a related topic 'Setting up Ubuntu as a Penetration Testing and Development Platform', however the aim out there was a setup a development and penetration testing environment on the same box. That post is still valid and can be referred to, but I have found a better approach to setup a  development box as compared to the method explained in that blog post. You can still follow the penetration testing setup as explained with that post once you are done configuring your system for development as explained below.

So you might wonder, why did I completely reconfigure my development system, within such a short time, and spend some more time documenting the new method? The answer is the immense 'Value' and 'Productivity Gain' this new method has to offer, and all this is possible by a single tool call Vagrant.

If you have been developing applications in a team/enterprise environment, you should be familiar with one or more of the below challenges.
  • Manual Setup - for most developers setting up their development system is a manual activity, pretty much as explained in the earlier blog post 'Setting up Ubuntu as a Penetration Testing and Development Platform', whereby components that form the development stack (like sdk, appserver, database etc.) are installed manually on the machine. This manual process takes a long time to complete - especially for very complicated setups, and anything manual and complicated is prone to errors (as you might miss that minor but critical configuration step). This makes ramping up a new developer or a new team extremely time consuming.
  • Multiple developers and Multiple Projects - Considering you are in the manual setup mode as discussed above, you have managed to get the system setup for one project, but there is a need to work on a different project for a short time. Keeping the environments of these two projects is a big challenge for a single developer. Now consider this situation with all the developers in your team, and very quickly the team will end up in a situation where none of your development environments are in sync in terms of a configuration.
  • Works on my machine - The above situation gives rise to bugs where things work in the environment of some team member, but does not on others. These types of bugs are the most tricky to resolve, because we do not know which is the correct configuration to use.
  • Development vs Production environments - Since developers have tweaked their local environments considerably to make things work, their configuration may not be in sync with production, which can result in unexpected errors in production.
  • No cross platform development ability - If your production server is Windows/ Linux but you use a Mac for your coding (as it has a more soothing development environment) you can enter into tricky situations where you may need to run windows virtually on your Mac, or are forced to use a OS and tools that you are not comfortable using.
  • Productivity - Notice that in most of the above situations the developers are busy grappling with bugs related to system configurations, or tweaking system configs, getting comfortable with new development environments etc…basically doing everything other than coding, or fixing bugs purely due to coding issues.
The above are challenges faced by a single developer too, but consider the impact on productivity in a large project, with multiple developers, usually not geo co-located. The impact on productivity are profound in this case and can mean the success or failure of a project. So let us now talk about the solution.

So what is Vagrant?

Vagrant is a tool that runs on your development box/workstation, typically referred to as GUEST, and builds up on a virtualization provider (like VMWare, VirtualBox, etc.) and uses a provisioning tool (like Chef, Puppet or simple shell scripts) to create a virtual development environment, typically referred to as HOST, that is configured per your needs without manual intervention.

You really need to experience it, to understand its power and it is practically impossible for me to explain the same in words. Try it out, before you read further, and I guarantee you will be amazed to see how easy it is to setup a development environment for web applications using just a few commands.
  • [ToDo Activity] Visit my GitHub repository and try out steps 1 to 4 as explained in the vagrant-webdev project.

How about the above challenges ?

  • Manual Setup - not needed any more, since the provisioning tool takes care of it in an automated fashion. You may argue that creating the provisioning script takes time. Yes, agree, but that is a one-time activity. Moreover provisioning files are mostly written by operations team (the people that manage your servers) , who are well versed with provisioning tools like Chef and Puppet. Developers are only required to clone the repository, fire up the development environment and start coding. Any additional configuration changes can be easily rolled out to the entire development team, by asking them to pull the latest configuration code from the repository and recreate the vagrant machine.
  • Multiple Developers and Multiple Projects - Since all developers use the same repository to setup their development environment, there will never a a discrepancy in terms of the environment configurations. The configuration changes are tightly controlled by the operations team so less possibility of it getting out of sync. If one is working on multiple projects they can create one vagrant dev box per project and that way each project can maintain its environment sanity.
  • Works on my machine - Since the environments are  similar, and assuming code base is similar the code is guaranteed to work in the same manner.
  • Dev vs Production - the provisioning scripts used to create development environments are exactly the ones used to create the production environment. This means less probability of encountering issues in Production that were not encountered on Development.
  • Cross platform development -  Vagrant is available for Windows, Linux as well as Mac GUEST. The options available for HOST are abundant that you will not need to create a box of your own. In any case, if the readily available boxes do not meet your needs, there is an option for you to create a customized one too. See References section.
  • Productivity - No brainer here, finally the developers can focus on coding and let the system configuration be with the Operations team.
  • And more - these are just few of the benefits, you will discover endless more when you start using it.

Personal Opinion

While working on vagrant-webdev I was faced with the dilemma of selecting a provisioning tool/language. I had the option of Shell Scripts (simple, quick, flexible, prior knowledge), Chef or Puppet (both unknown to me). I ended up selecting Puppet because
  • There was something new to learn here
  • Better support and backing from puppet labs.
  • Lots of modules readily available from puppet forge.
  • Syntax more catered towards developers.
I recommend using ready made boxes available from Puppetlabs, and then using puppet to add the required applications part of your development stack as done in vagrant-webdev.  

References

Posted by Hemen Kapadia at 5:01 AM
Labels: , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)