In this chapter, you will learn about the current state of development in DevOps, how Vagrant fits into DevOps, and how to use Vagrant as a day-to-day DevOps tool. By the end of this chapter, you will have a much better understanding of how Vagrant can be used for development as part of the DevOps process.
As mentioned previously, DevOps is a mixture of software development, operations/system administration, and testing/quality assurance. DevOps is not a new movement, but one that doesn't necessarily have a leader or a set of rules and standards to follow. Every company has their own idea of what DevOps is and how it should be implemented. Many follow similar paths or rough guidelines. Due to the lack of governance with DevOps, the current state of development is varied.
Traditionally, development has always been separate to the operations and server team, but in the last few years, we have seen many DevOps tools bridge that gap and make life easier for both sides.
In the past, when a web developer would build a web application, they would code it, built it locally on their machine, and then FTP (file transfer) the files onto a live (production) server to then run the code—if there were any issues or bugs, the developer would have to make changes to the server environment and debug the code. There are many developers who still use this workflow and it may be because of their environment or because they have no choice in the matter.
Today, a modern web developer's workflow may look like this:
- The developer writes their code locally but through a virtual environment/machine with a tool such as Vagrant. This allows the developer to set up an environment such as the production one.
- The developer edits to their code and uses version-control (such as Git or Subversion) to manage changes. The version-control is set up in a way that allows the developer to keep test/new code separate from the production code.
- A continuous integration (CI) tool (such as Jenkins or Travis CI) is used to create a pipeline that often has three separate stages—development, staging, and production. The CI tool can be used to run tests against the software, and run scripts such as performing assets by combining and minifying them. The version-control software can be linked into the CI tool, which often triggers these builds and tests. When the developer pushes some new code to the staging environment, tests can be run before it reaches the production environment.
- Often, if the tests run and there are no issues, the code may be pushed directly into the production branch in the version control. At this point, the CI tool may trigger a new build, which would essentially restart the service that the code applies to. This could be simple or complex, depending on the production environment and software architecture.
- At some stages during this process, there may be manual intervention by the QA (quality assurance/testing) team or more senior developers who wish to check the code before it goes to production.
Of course, this is just an example workflow and will differ between companies and development teams. The modern workflow may seem much more complicated and tedious, but this is for good measure. At each stage, you'll notice there are checks and tests run before the code can reach a live production environment where real users may be interacting with that code. This can be incredibly important when working with financial software and other business-critical software. This modern workflow greatly reduces the margin of error.
Modern development in the DevOps world is focused on speed and automation. The focus on speed is the ability to quickly build a feature or fix a bug and "push the code to production" (a phrase you might have heard!). This means that single developers or a team of developers have less of a barrier when working on the code. A developer shouldn't worry about configuring servers or environments.
Automation is a big part of DevOps, and that effects the development part too. You can imagine how slow a process it would be if a developer made changes to their code and then had to wait for a member of the operations team to manually run tests and scripts against their changes before letting them know the result.
I believe that Vagrant is a key tool in a developer's toolbox in today's DevOps-focused world. Vagrant is essentially a suite of tools that allows the developer to create code but also connect with configuration management tools, such as Puppet, Chef, and Ansible, that are used to automate workflows and environments on servers.
Vagrant's primary focus is on development and enables an easy way for every developer on the team to use the same environment. Within a Vagrant environment, you can run version-control that could link into the CI workflow, which allows you to run tests and move code into different stages.
Vagrant is a flexible tool that enhances day-to-day development by allowing you to easily test out DevOps workflow ideas. It allows you to separate your software code and infrastructure without having to know much about DevOps, infrastructure, servers, and configuration-management tools.
As a day-to-day DevOps tool, Vagrant can be used for many things, including the following:
- Testing software code in different environments and operating systems
- Testing different workflows using configuration-management tools, such as Chef and Puppet
- Working in the same environment as other developers in your team/company
- Easily make changes to Vagrant and see the results instantly
- Running multiple environments/virtual environments to test out networking, file-sharing, and other multi-server use cases