Published: Jul 14, 2020

enabling “as code” mindset using DevSecOps

The desired state for organisations is to have the ability to do continuous delivery with speed and application stability. This has led them to adopting DevOps – a set of practices that integrate development and operations to promote collaboration between previously isolated teams.

DevOps incorporates a continuous feedback mechanism that allows ongoing improvement aided by automation. Security has also been included into the framework, leading to the term DevSecOps which encompasses speed, quality and security in application development

To ensure that environments can be easily managed and automated, we advocate approaching DevOps with as-a-code mindset, which focuses on continuous integration and infrastructure management. This makes all components more maintainable and facilitates a means to govern the deployment of infrastructure.

In the case of continuous integration/continuous development (CI/CD) for example, the “as code” mindset helps to ensure that development pipelines can be easily defined, tracked and changed. For instance, with Jenkins pipeline implementations using Jenkinsfile, approval mechanisms can be set in place and managed by the development teams as they would for any other code. This helps with change control and audit. Change history can be traced and when configurations go wrong, developers would have a way to rollback easily to previous configurations, without the need to keep backing up the entire Jenkins job configuration.

With infrastructure as code, teams will be able to replace entire environments with the assurance that all configurations would be consistent. For example, in cloud-based environments, scripts can be used to define everything from virtual machines to firewall rules and network layout, and provide the assurance that each component will have the same configuration every time the script runs.

Approaching DevSecOps with an “as code” mindset ensures that application development environments can be easily managed and automated. It makes all components more maintainable and provides a way for entire infrastructure models to be governed.

The “as code” approach can also be applied to the setup of workstations.

System and software engineers developing applications and maintaining infrastructures face an ongoing challenge in setting up complex workstations to help them do their job. A new member who just joined the development team is usually given documentation with instructions on how he can set up his machine. This often involves installing different toolsets, integrated development environments (IDEs) and setting up environment variables – tasks that will probably require assistance from his colleagues and take a full day to complete.

The same laborious tasks confront existing team members who get a laptop replacement, or a trainer who needs to set up environments for application training. These are just some of the use cases for automating the setup of workstations using the “as code” approach.

Scripting your Windows environment, for example, will deliver benefits such as:

Developers may make mistakes by downloading software and installing it without verifying the authenticity of the download and the site that they are downloading it from. The “as code” approach eliminates this risk by ensuring that you always get the correct, legitimate software by configuring the setup to download from a trusted repository.

Speed of deployment and setup is improved by automating the retrieval of executables from the trusted repository

Version updates can be easily managed and distributed across the entire organisation.

Setup is less likely to fail because the version and configuration of the software is controlled by the script.

• Enhanced security:
• Speed:
• Improved version management:
• Successful setup:

The “as code” approach thus reduces the effort needed to set up environments and workstations, enabling teams to achieve better time-to-value, and to deliver greater flexibility and agility to the organisation.