DEV Community: Sachin Gupta

Client Devsecops

Sachin Gupta — Thu, 30 Nov 2023 23:55:13 +0000

This is a 5 articles series on how to design and implement more scalable, agile-aligned, and futuristic “Devsecops”.

This is the 5th article in the series.

If your platform is multi-client, you need devsecop to create client context(tenant) and associated rules, policies, configurations, data-pipelines etc. Many a times, this includes spawning new microservices specific to your client.

Client context should be deployed per platform, so as defined in infrastructure and platform devsecops, platform manifest file should have a place-holder for specifying client contexts to be deployed.

Client specific configuration itself can be maintained in client manifest, which would be referred in infrastructure manifest file.

Client deployment should have separate workflows, that should be invoked based on clients list to be enabled for a deployment or not. Client identities should be maintained in infrastructure vaults.

Application Devsecops

Sachin Gupta — Thu, 30 Nov 2023 23:47:23 +0000

This is a 5 articles series on how to design and implement more scalable, agile-aligned, and futuristic “Devsecops”.

This is the 4th article in the series.

As discussed in previous article Application devsecops should be agile aligned and should facilitate development teams, QA teams and Release Manager.
Importants points to consider during Application devsecops are following –

Code management should be handled entirely by development team.
Code should be released in packages for feature testing and for release testing, and same package should move from QA, Staging to Production. This puts the requirement that any code developed be it UI dashboards or workflows or anything, it should be portable across environments.
Continuous development should be facilitated by relevant CI pipeline and stages for code review, unit testing, code coverage, vulnerability scanning, pen testing and put CI gates to make sure only relevant code will go for QA.
Continuous integration of the code should be facilitated by automatically generating nightly builds and running automated regression suits to ensure anytime merge code is deployable.
Continuous deployment should be facilitated by deployment pipelines that can deploy various releases and feature releases one touch on various environments seamlessly with built-in approval process with different approvers per environment.

Most important base for application devsecops is the branching strategy of your code repo. Code repo should facilitate parallel development, testing and releases.

It should consist of three branches mainly –
Feature branches– For parallel development of features. Owned by Development
Continuous Integration branch – For continuous integration with ready to deploy code. Owned by QA.
Release branch – For releasing package to production. Owned by Release Manager
Production branch – For production release. Owned by SRE.

Presented below is a devsecops strategy for application development and deployment. Indicating various branches, roles and pipelines facilitating the development, validation, release and deployment of your software projects.

Generative AI to enhance Continuous Integration
With generative AI, CI pipelines can be extended by doing chat-gpt reviews for code other than manual reviews.

Agile Aligned Application Devsecops

Sachin Gupta — Thu, 30 Nov 2023 23:02:44 +0000

This is a 5 articles series on how to design and implement more scalable, agile-aligned, and futuristic “Devsecops”.

This is the 3rd article in the series.

Devsecops is mainly for software development and release, but if the software development process is agile based, it is important for devsecops to align with Agile and streamline along with Agile processes.

Devsecops shouldn’t just facilitate CI-CD pipelines for testing of code, creation of artifacts or deployment of artefacts, but devsecops should also facilitate agile process flow, by integrating agile process related communication like release of build to QA integrated in the pipeline. Same way with deployment too once the platform is ready a notification is required. Same when Release Manager cuts a release communication of release artifacts should automatically go to QA and SRE, QA validation completion notification should automatically give release notification for production deployment.

Besides this for each feature Jira ticket should automatically get updated to keep track of feature current state. This all can be done by integrating CI-CD with Teams channels/Slack, Jira and Confluence.

Infrastructure & Platform Devsecops

Sachin Gupta — Thu, 30 Nov 2023 22:34:21 +0000

This is a 5 articles series on how to design and implement more scalable, agile-aligned, and futuristic “Devsecops”.

This is the 2nd article in the series.

Platform should be represented as a configuration, which dictates the configuration of the platform deployed. Platform configuration should give enough knobs to dictate the component configurations and deployment method.
Manifest files – Defines full platform in a single configuration.

*Deployment Flavours *

*Deployment Methods *
 Disrupting - This is suitable for non-production deployment, where requirement is to deploy as fast and least costly as possible.
 Non-disrupting or Make-before-break - This is suitable for production deployment, where there is a requirement to have no disruption or minimal disruption.

Component Versioning
This allows versioning of platform components that can be then independently tested and rolled into different deployments.

Global Deployment of Platforms
Global deployment, management and monitoring is sometime crucial for infrastructure devsecops. There are certain requirements that needs to be fulfilled for achieving that.

Centralized Management – Infrastructure devsecops should be able to manage all the platform from a single place. In this case manifest file is the source of truth and repo is that single place. Beside this platform component feature release and deployment will also be taken care by component versioning.

Centralized Monitoring – Each of your deployment should have monitoring components deployed that will feed into a central monitoring unit managed by SRE engineers 24x7. Automatically devsecops should deploy telemetry components and integrated this with centralized monitoring and alert.

Centralized Secret Management – All the platform secrets and states should also be centrally managed and controlled. Secret refreshments and updates are very much integral part of deployment.

Deployment Governance – Necessary deployment approval and review process should be integral part inbuilt into devsecops.

Agile Devsecops

Sachin Gupta — Thu, 30 Nov 2023 18:06:22 +0000

This is a 5 articles series on how to design and implement more scalable, agile-aligned, and futuristic “Devsecops”.

This is the 1st article in the series.

Design and Implementation of Scalable, Agile and Futuristic Devsecops

Purpose of Devsecops implementation is to automate software development and operation, blending nicely with Agile process and should be future looking.

A devsecops stack should mimic your full stack.

Devsecops should automate infrastructure deployment for various environments (dev, validation, staging, production) providing different flavours. Besides this it should be able to manage and monitor those platforms and should manage secrets too centrally. There should be a tight control in terms of reviews and approval who can deploy infrastructure components.

Same way if you are building your own microservices for platform that too should be centrally developed, managed, and deployed falling through full agile process.

Application and feature development should facilitate agile aligned ci-cd and should provide central release management too.
If your platform supports multiple clients, then tenant creation for customer and any policy, rules and customer specific configuration too should be automated and centrally managed.