DevOps and Dealing with Software Project Delays

Printer-friendly version

Software development is fraught with risks, including projects that fail to meet their deadlines. Technology professionals who value their careers need to understand the latest tools and techniques including DevOps, which embodies excellent concepts and practices that have been taking the industry by storm.

Operations professionals and agile systems administrators, among others, are looking for better approaches, including collaboration between development subject matter experts (SMEs) and the IT operations professionals who ensure continuous availability of IT services. DevOps depends on excellent build and deployment procedures, and DevOps engineers need to understand that there are many challenges inherent in building, packaging, and deploying complex software systems. 

If you get these procedures right, your projects will benefit from a much faster time to market. But there other challenges that need to be overcome.

The build engineer can sometimes feel challenged due to a lack of the requisite technical knowledge necessary to get the job done. Successful build engineers often find that it is very helpful—sometimes absolutely necessary—to be embedded with the developers so they can stay on top of all of the technology changes that developers deal with on a day-to-day basis. DevOps matters because it puts the focus on developing build, package, and deployment procedures early in the software and systems lifecycle.

Automated builds begin with effective source code management strategies including baselining through the use of version labels and tags that can identify all of the exact versions of the code and automated build procedures using tools such as Ant, Maven, or Make. The deployment process itself must be fully automated and traceable.

Many build engineers are separated from the developers in order to comply with regulatory requirements for a separation of controls. This requires that the build engineers report to another manager who is not within the development organization.

There are many reasons for this requirement and failure to comply will result in audit findings and even regulatory violations in some industries. There are very practical reasons for a separate build engineering function. The first time that a build engineer attempts to create a release of the code the build process often fails. The reason? Developers often forget to check-in all of their code, including build dependencies such as libraries. The independent build tests to ensure that the build process is complete and fully automated.

Build engineers embed immutable version IDs so that the baseline configuration can be verified. This essential procedure ensures that the correct version of the code is deployed to production. In CM technical terminology this is called a configuration audit and, once again, is often an IT audit and regulatory requirement. Build engineers establish a continuous integration server to automatically build, package, and deploy the code upon the checkin of code (or sometimes nightly or upon request).

Build and deployment engineers often need to operate within the established change management policies, especially when deploying a release to production. Most of all, build and deployment engineers understand that they must exist within the greater ecosystem of the application lifecycle.

DevOps seeks to streamline the entire build, package, and deployment process. Many of these concepts are not new, but DevOps communicates them effectively and presents a compelling approach to build and deploy. DevOps can certainly learn a lot from build and deployment engineers, and brings some compelling lessons that can help streamline the entire release pipeline. If you want to be successful, then you need to learn DevOps process and procedures.

Printer-friendly version

Something to say? Leave a Comment

Bob Aiello

Bob Aiello is a consultant, a technical editor for CM Crossroads, and the author of Configuration Management Best Practices: Practical Methods that Work in the Real World. Bob has served as the vice chair of the IEEE 828 Standards working group and is a member of the IEEE Software and Systems Engineering Standards Committee (S2ESC) management board.