Organizations that develop and deploy a lot of custom software have learned to deal with issues related to having many programmers touch those products along the way. Programmers have differing skillsets and competencies, people tend to make mistakes, and there is a constant struggle between the developers trying to make the programs work and the security teams who will need to ensure that they are safe once deployed.
The result of all this chaos is that software development is often strung out over months or years, with developers sometimes having to start all over again if a supposedly completed program doesn’t do what it needs to, if it can’t deploy properly into the environment, or if some security flaw is discovered long after the program has been put into production. Further, those security holes are often only discovered after an attacker has exploited them, which can cause huge losses of both data and revenue.
It’s that last area, about security, that probably led Gartner to list DevOps (a combination of the words development and operations) as a hot cybersecurity topic. DevOps has come to mean a lot of different things, describing everything from a movement, technical software or even a cultural shift in how programs are created. In general, it can refer to any effort or practice that emphasizes the role of collaboration and communication between software developers and other IT professionals, such as the system administrators who will be overseeing the operations and security of the programs that developers create.
As such, DevOps is now being embraced by many groups. But saying that you want to start a DevOps program is a little bit like saying that you want to travel around the world. It sounds like a great idea, but the challenge is going to be implementing that vision, planning how to do it efficiently, deciding what modes of transportation to use, working out a schedule and then executing it in the most efficient way possible.
In DevOps, this process is further complicated by the sheer number of tools that developers must use to create programs, each with their own specialty. Any management program would need to perfectly integrate those tools, be it Bamboo, Otto, Chef, Puppet, OpenShift, Fortify, RapidDeploy, CruiseControl, Jenkins, Broccoli, Gulp, Github, New Relic or the hundreds of others that programmers employ for various software creation tasks. And it would have to be able to link into any of the environments and operating systems, both physical and cloud, where the programs will eventually reside.
The XebiaLabs DevOps Platform somehow manages to do all that, within almost any environment, and for just about every platform. The program is divided into two components, XL Release, which provides a management interface for the software creation process, and XL Deploy, which helps to install completed software into the environment. Both parts of the program are available bundled or separately, and are sold based on a yearly subscription model depending on either the number of users for XL Release, or the number of deployments for XL Deploy. Both were examined as part of this review.
Both parts of the XebiaLabs DevOps Platform are generally installed on premises by users. It can work in the cloud, but connectivity issues when checking and testing programs generally leads most users to install XL locally. But it works fine in a cloud deployment, as was tested here.
Testing XL Release
Once XL Release is installed, administrators can begin defining their projects – the software they are creating – to the program. This can be done using templates, starting from scratch, or using a template and then modifying it to suit the development environment. Templates look like timelines or flowcharts and define every milestone and process that a piece of software in development needs to go through while it’s being created. Separate groups can be assigned tasks as well as the tools they should use to accomplish them. Security is paramount at this phase, and it is extremely easy to define what different users and groups can and can’t do with the program in development.
Once the template is completed, users can see what tasks are assigned to them and get to work. Everything they do is tracked by XL Release so administrators can see at a glance the status of every program that is in development. You might, for example, assign a security assessment task at one point, or a configuration of a test environment, a quality control check, smoke tests or any type of process needed as part of software creation.
Users can interact with the XL Release system as well at this point, generating reports about each stage of development assigned to them. They can raise flags for issues such as out of date credentials, which might generate a yellow alert and pause development until corrected, or report that a program failed a run test or crashed, which would throw up a critical red flag for immediate response. The main dashboard is dynamic based on those interactions, so administrators can easily see how all their active projects are proceeding, and the reason and cause for any delays.
Adding the ability to manage the whole DevOps software creation process though XL Release brings both order and the ability to visualize a very complex process. While that alone provides a huge amount of value, XL Release can then be used to add automation, which has recently become more of a standard practice for DevOps.
Adding automation is surprisingly easy, owing to the fact that XL Release is integrated with just about every developer tool that one could possibly use. Looking at the template for a program’s development, it’s easy to see areas where tasks like smoke testing are assigned to humans. Alternatively, you can automate those processes, asking XL Release to perform the testing automatically as part of the creation process, and then perhaps asking humans to check over those results. Administrators could also opt for full automation, accepting passed tests as valid and pushing on to the next phase of development. Automation won’t solve every problem, and won’t work with every stage, but where it can help, XL Release makes it very easy to implement.
Testing XL Deploy
Available bundled or as a separate subscription, XL Deploy takes completed programs and makes them easy to install in multiple environments. Here, too, the ability of XL to work with nearly any deployable environment makes this process fairly straightforward. For this test, a program needed to be deployed through JBoss, Apache and SQL. It also needed to interact with a database to grab current information.
Thankfully, no programming was required. XL Deploy was simply told what environments the program needed to go into, selected from a dropdown list showing the current environment. It knew, for example, that rollback protection needed to be created for the database interaction component in case a new version of the program started having problems in the future. It also knew that the Apache server required a reboot to give the program full functionality, and added that to the deployment schedule.
With XL Deploy, we didn’t even need to know how the deployment worked. We just pointed to the environments, and it took care of all the heavy lifting. Once complete, a full audit log was generated showing everything it had done. And just like that, we closed the loop on a program that was rapidly created and deployed using DevOps procedures, processes and culture.
Any sufficiently large DevOps-based software design effort is going to require some type of management program to operate and deploy efficiently, and the XebiaLabs DevOps Platform is one of the best we’ve experienced.