Getty Images
DevOps automation: Examples, tradeoffs and best practices
Automation can be a faster way of doing things right or wrong. Planning and review can determine which outcome will prevail on your DevOps automation project.
IT teams are increasingly automating DevOps processes for faster and more successful software delivery. However, balancing the tradeoffs of increased automation is crucial to reap the rewards.
DevOps consists of five main phases: application planning, program development, building, testing and deployment. These phases are comprised of a mixture of tasks that require considerable skill and expertise. But many of the tasks are dull and repetitive. They tie up skilled personnel, and there's a lot of room for human error, which can compromise application integrity. Automating the last four phases of DevOps can increase efficiency and success.
Atomic vs. systemic approaches
There are two approaches to DevOps automation. The atomic approach develops and deploys whole applications with relatively little component sharing and a monolithic structure. The project's phases are distinct, and it's possible -- even advisable -- to deal with automating tasks in each project phase individually. In hybrid cloud applications, the back end or core transaction processing piece of an application is often developed atomically.
Systemic automation targets the last three or four DevOps phases and creates a development pipeline. In systemic automation, the tools and procedures for each phase connect seamlessly with the other phases. Therefore, this approach is usually characterized as a single unit and encompasses practices such as rapid development, agile development or continuous integration/continuous deployment (CI/CD).
Most users of the systemic approach develop componentized applications in an environment where there's a high rate of software change, a sharing of components across applications and concurrent development. Tools that cover the full range of targeted phases are best, so look for packages that use those unifying characterizations to describe their scope. Lastly, don't use systemic automation where it doesn't fit; it will add complexity.
Automation tools for the development stage
The minimum element needed to integrate an automated tool into a workflow is a repository or single source of truth. GitHub is a popular tool that serves as an integration point for the five DevOps phases and links tasks between phases. From this repository base, teams can launch automation strategies for each phase and facilitate integration across the phases.
IT teams can automate program development through assigning AI tools routine tasks, such as support of junior team members, code review and API call writing. GitHub Copilot is one tool that can suggest code based on context and learned practices. Other tools include ClickUp, which also provides project management features; CodeT5; OpenAI's Codex; and Codiga, which offers code review.
Code-generating AI tools can make mistakes, so their output should be subject to stringent human review. Enterprises warn against using AI tools to review AI-generated code, even if different tools and AI models are involved.
While these tools support a dozen or more programming languages, certain tools are stronger in certain languages. Organizations that focus on a single language should check to see which tools are best for that language.
Automation tools for the build, test and deployment stages
While it's possible to automate the build, test and deployment phases atomically, most users treat these three phases as a single unit when considering automation. Automated testing products have grown to include build and deployment automation, and popular tools like Jira and Jenkins now address all three phases.
The testing phase has used automation the longest out of all the DevOps phases. The testing tool Selenium is well-suited for atomic and systemic DevOps automation because it integrates well with other tools in the build/test/deploy string. Appium is another similar tool that's especially useful for cross-platform development. Many of these test automation tools like Selenium now incorporate AI, which is valuable in unit test missions like API testing.
Automated testing can create two problems. The first is that it may generate redundant tests and, therefore, could miss conditions that are critical to data validity. This can happen when developers fail to include the proper testing APIs/hooks in the code to guide test data generation. An application architect should work with test development to ensure test optimization.
The second problem is that teams often don't maintain and update test data generation hooks throughout software changes. Teams can resolve this by making test data generation updates a specific part of any project involving changes to current software or software additions that impact functionality.
There are two options for deployment automation. Containers are the go-to strategy for enterprises in both data center and cloud. Kubernetes uses parameters to control deployment and redeployment and is compatible with repositories. The second option is traditional DevOps tools like Ansible, Chef and Puppet. They work equally well in the data center and the cloud.
Increased automation tradeoffs
Introducing DevOps automation projects could create certain issues. IT teams that address these four can mitigate the potential tradeoffs of increased automation.
Fear of complexity
Many enterprises believe that adopting DevOps automation is complex and that the resulting workflow is more complicated than it was before. It does take thorough planning and some retraining to use DevOps automation, and poor project planning and execution could produce complex results. But with proper project discipline, DevOps automation will reduce complexity.
Application security
Maintaining security during DevOps automation will vary from phase to phase. The high-level goal is to protect software by securing access to code and builds. Teams can accomplish this through controlling repository access and managing pull/push rights. When development automation suggests library components, teams must manage the available libraries to ensure that a suggested library isn't compromised. This is often overlooked when AI makes code suggestions.
Contaminated code
Automation can increase the risk of introducing contaminated code -- including library elements and self-developed components -- at the build stage. Build automation can hide the details of assembling software for testing and deployment, which raises the risk of substituting malware for legitimate software components. Build automation should draw code from the repository, which should use access security technology to manage versions and integrity.
Loss of human awareness
When DevOps automation takes on many roles, human review is difficult. The DevOps team becomes used to having the tools make decisions, and they lose awareness of the workflow that underpins all of DevOps. The last step in any DevOps automation project should be a walkthrough of the entire project flow to assess where professional review should occur. Teams must ensure that the information available at those points will satisfy review requirements.
