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.