Introducing Combox: a simple tool to deploy virtualized development environments
18/04/2013 - Laurent Eschenauer (@eschnou)
In this blog post, we introduce the concept of virtualized development environments, helping software developers in a team to avoid inconsistencies between themselves and, most important, to align their environment to the one used in production. This is the second post in our Software Development serie, highlighting how ComodIT can be used by development and operation teams to streamline their processes and communication with a DevOps mindset.
Local environments are a mess and should be avoided
Not so long ago, the first thing I would do when starting a new project was to configure my local environment with all required components: web server, language frameworks, database, etc. If I was working on an existing open-source project then I would first read the README trying to figure out what to install and configure to just get the project to work.
If you are still doing this today, then you are using what one call a ‘local development environment’. You install all components on your local workstation, running code in the same place as where you write it. This causes a lot of challenges you have probably already encountered:
- How to manage differences between local and production environments?
- How to work on multiple projects with conflicting requirements?
- How to ‘restart from scratch’ to test your code work on a fresh system?
- How to easily develop and test the packaging and deployment?
- How to test upgrade path from known versions/states?
A continuous source of tension between devs and ops
There is nothing more frustrating than having a piece of software working on a developer's workstation, and failing on someone else or when deployed in production. Time is lost trying to understand the differences between the different environments: package versions, configuration files, access rights, SELinux contexts, etc.
Even more frustrating is for a developer to realize that a dependency he used locally can't be deployed in production because the ops team insists on sticking on packages available in the official repo. These kind of conflicts between developers and operational team are a waste of time, they impact the team's morale and can be a cause of downtime in production due to lack of testing of the integrated components.
The good news is that all of this can be easily avoided with one simple process: virtualized development environments. We have been using this internally for all our developments and today we are releasing our toolchain in open-source.
The benefits of moving your development environment to virtual machine
Here is a simple idea: deploy a development environment in a virtual machine, matching the production setup as closely as possible, and expose your local code to the virtual machine through local shares.
With such a setup, you continue to write the code on your local workstation with your favorite IDE and code source management tools. But you are actually running the code in the virtual machine, against a production like setup. Being forced to run the code you write in an environment matching your target environment will help you catch issues as soon as possible and take the right action well before release day.
In addition, if you can automate the deployment of this virtualized environment, it means that:
- All developers have exactly the same setup
- Moving to a new laptop or os version is not an issue, the VMs move with you
- Testing your code on a fresh system is done in minutes: teardown/re-deploy the VM
- You can reuse this automation to deploy test/staging or even production servers
Introducing Combox: simplifying development environments management with ComodIT
We are introducing Combox, a command line tool to quickly deploy and teardown virtualized development environments on VirtualBox, using your ComodIT recipes. Using combox, getting started on a new project is as simple as:
git clone https://github.com/storytlr/storytlr
cd storytlr
combox setup
combox deploy
Once deployed, you can immediately start using the application. In this case, it is a web app, and the recipe makes it available on your localhost, port 8080. So, just open your browser and get started. Since it is a PHP application, any changes you make in your local source tree will immediately be reflected in the live application.
A short screencast to show you how this works
Other posts in this serie
blog comments powered by Disqus