is DevOps just a toolbox?
absolutely not!
There are more important elements in DevOps than tools, but tools are essential. Choosing the right
tools become, therefore, critical to DevOps successes. DevOps causes a perspective shift toward perceiving software as a means rather than the destination. Software achieves its purpose if it solves real world needs so it’s important to be able to determine if changes to software lead to the tangible benefit of revenue.
DevOps planning tools
The planning tools for DevOps need to have all the benefits of being agile. Responding to changes rather than rigidly “sticking to the original plan”. Being dynamic while achieving small victories towards the envisioned implementation. All this planning must enable guidance to remain within the system, department, and organisation vision. Tools with a holistic and complete view of the entire process serve the need for “many pieces orchestration”. Organizations often lose dedicated focus in the details of individual tools and processes unless they have a complete view solution in mind/place. The organisation needs to be able to manage this change within its future. A future that can only be successfully reached if changes are within estimates or at worst within its safety financial margins for planned change. Return on investment needs to be achieved in the planned time and DevOps implementers have this critical planning responsibility.
DevOps coding tools
Software changes over time. Unsurprising to anyone in DevOps. With experience in creating software comes the realisation that an ability to track history and jump around to different versions of the source code is mandatory. Experienced technology project leaders may remember a time when they weren’t familiar with version control yet. It usually meant copies of source code directories in various states of change. It was chaos to manage and even harder to understand. Such manual and ad-hoc systems usually failed to successfully get back to known good states or to manage the historical trail. Software teams need to be able to experiment, and either move forward or return easily. They need to know where they’ve been and make fixes to any point in history along the way. They need to be able to adopt some changes and reject others and this makes effective version control fundamental to DevOps toolsets.
There are many options available for software version control. Git has emerged as the standard because of its embrace of open source, distributed nature, high performance, and remarkable support for multiple workflows.
Modern teams need more than just version control, though. Azure DevOps, GitHub and Bitbucket are tools that extend Git, offering access control and collaboration tools for collaboration in source code. These features include visualizing source code changes and history, issue tracking, and pull requests (also called “merge requests”) that enable code review in integrating work on different features and from different team collaborators.
DevOps building tools
Building software can be simple. It often is. There are many different configurations, though, that a build can take. Some build parameters control optimizations and platforms. You can make build output with debugging symbols, or not. Manually building can result in building wrong versions of your code. If your build is not automated, you regularly run into issues with inconsistent build results. Organizations have had issues because of deployment of something that wasn’t built correctly. Build servers operate in this niche and resolve these issues.
By using software to build in a consistent and accepted configuration, builds automatically use the expected version of the code and are repeatable. Teams no longer find themselves risking what they’re building or subsequently deploying. Automated tests after every build should run on build servers.
Having a build server enables continuous integration. A dedicated build server can trigger builds for every commit that gets pushed to the canonical repository. It means that each update to the source code is integrated into a build that is ready for automated testing, manual testing, acceptance testing, and could even immediately deploy to production. Teams that work in isolation tend to have problems when they try to integrate. Continuous integration translates to integrating work early and frequently, so issues get addressed effectively and quickly.
DevOps testing tools
The testing tools for DevOps will be discussed in next week’s article…
In WiRD’s experience it is important to be clear on which tools will be used for each DevOps category; as well as how these tools will interact with each other; before deploying them. Some combinations of these tools just work better than other combinations. Here is a link to a free introduction lesson on DevOps
What has your experience been with regards to deploying DevOps tools? Please share your experiences with WiRD by commenting or interacting on LinkedIn.