DevOps is a relatively new concept, adopted by more and more businesses – breaking down the barriers between development, quality assurance (QA) and IT operations, to result in a much more rapid and fluid software development lifecycle (SDLC). However, there are almost certainly a number of organisational and technical issues which make your experience within DevOps less seamless (and more frustrating…) than you’d like.
Our discussions with DevOps are wide and varied, but we do hear a number of repeated pain points. How many of these do you identify with?
1) “Testing is too laborious!” – Manual testing
A key element of successful DevOps is continuous integration / delivery, which depends on automated testing, yet many organizations still rely on largely manual testing processes.
Manual testing is also more error-prone, so system stability is compromised. This leads to pain later on, as the smooth DevOps SDLC flow is interrupted by the need to implement unplanned fixes.
Automated test harnesses, which prevent failing code from being integrated, are essential. This also results in dev taking more responsibility for testing and QA. TestComplete is a good choice, which offers comprehensive automated testing for web, mobile, and desktop software. For conducting automated tests exclusively using a web UI, Selenium is also a popular option.
When running in a containerized environment (e.g. Docker) your CI/CD pipeline becomes the center of gravity for building your software containers and running your entire test scope. Here we’d recommend tools such as drone.io or codefresh.
2) “It worked there but it doesn’t work here!” – Inconsistent environment configurations
In an ideal world, all environments – development, test, and production – would be similarly configured, differing primarily in scale. This enables code to move seamlessly between environments until it hits production, with no drama.
Unfortunately, this isn’t yet how the world works, and inconsistencies between environments can lead to code breaking. This very much gets in the way of the ‘seamless and rapid’ SDLC concept which underpins DevOps.
As with many issues in DevOps, software containers such as Docker are the remedy. By virtue of being entirely self-contained, including all dependencies, containerized software should operate identically, regardless of the environment it runs on.
3) “Ops keep slowing us down! – Conflicting goals between dev and ops
Perhaps the biggest challenge of moving an organization towards a DevOps way of working are the historically competing roles of dev and ops. Essentially, dev like changing things, and ops like keeping things stable.
If dev and ops are simply thrown together in a single team, a culture clash is inevitable. Instead, management needs to impart the common goals of speed, quality, and reliability to both groups. To ‘meet in the middle’ dev need to accept more responsibility on their side (so they can’t just ‘throw code over the fence’ to QA), whilst ops need to trust what happens upstream and embrace a much faster release turnaround.
4) “We can’t possibly do every step of the SDLC this quickly!” – Non-Agile organizations
DevOps and Agile, while being separate methodologies, have a lot in common. The key crossover between them is that it is almost essential for a dev organization to be practising Agile for a DevOps way of working to be successful. Waterfall is simply too slow.
It is important to ‘run before you can walk’. Any organizational change, including DevOps and Agile, is a substantial undertaking, so companies need to be realistic about how quickly they change long-established ways of working. Of particular note are the many approval and sign-off processes which will need to be eliminated and / or consolidated to avoid becoming bottlenecks. It may make sense for dev to perfect Agile before attempting a full DevOps organizational reshuffle.
5) “Everything moves too quickly to follow proper security processes!” – Process and container security
Security can become an obstacle to DevOps if one waits until the end of the process, just before moving into production, to submit the results through the traditional security gates and control points. This echoes the earlier point regarding manual testing – if an organization relies on manual testing, tests (including those relating to security) will inevitably be skipped or rushed to meet a shorter available testing time, leading to security holes. So, like everything else, security too must be automated in DevOps environments, and integrated into the process as early as possible.
A case in point are Docker containers. Containers are usually built or instantiated from base images that are stored in registries. Developers pull an image, then use it as is or develop it further, then often build their own images. This lifecycle can be very rapid, especially in full CI/CD environments where every code commit by a developer generates a new image. There’s simply no way for traditional, manual security checks to handle such a huge influx of new code on a daily basis.
An automated process ‒ that scans images for vulnerabilities at every stage, ensures that image integrity is maintained along the entire process, enforces security policies on which images are permitted to run, and provides full visibility into the process allowing security teams to monitor and audit it ‒ is the only way to satisfy security requirements without impeding DevOps speed or changing its methods.
Furthermore, connecting such automated image assurance processes to your existing CI/CD pipelines (e.g. Jenkins, GO-CD, drone.io etc.) enables you to enjoy both worlds, rapid speed of development while your security policy enforced as part of the process. Aqua’s own continuous image assurance does exactly that.