The goal for a successful continuous delivery process is to minimize the time it takes for development teams to go from idea to usable software by practicing agile techniques and automating the entire software delivery system: build, deploy, test, release. This Refcard explains detailed patterns and anti-patterns for core areas of CD, including the delivery and deployment phases, rollbacks, pipeline observability and monitoring, documentation, as well as communication across teams and within the organization.
Vault and Safe
Vault is a secret management service by HashiCorp. It is a tool that will help you in storing secrets (API keys, passwords, etc.) and accessing them securely. You can use Vault with a user interface as well as through CLI.
In this post, we will not be going deep into what Vault is, but instead, will look at how we can migrate secrets from one Vault to another. We can migrate secrets from Vault using Vault CLI, but it can get a little complicated to do so. Therefore, to make things easy, we will use Safe CLI, which is a wrapper around Vault. It will help us in managing and migrating our secrets by using simple commands. It also helps us connect to different vault instances very quickly for migration purposes.
Traditionally, deployment artifacts were types of archives that were transferred to the target environment and installed there. They could be simple .zip archives with binaries, Java's .jar or .war files, or simply .exe executables, among others. It is worth saying that this approach implied preliminary preparation, like installing and configuring all software dependencies.
The situation changed when Docker appeared. Moreover, the principle changed: now we operate Docker images like some self-sufficient sealed units containing everything the app needs to work. But we have to admit that both principle and technology are relatively new to the industry. Many companies still rely on a VM-based approach and classic deployment artifacts. And it's quite clear why they do this: infrastructure is already bought; Ops teams are trained on how to deploy, manage and monitor applications; and so forth. In two words, this journey seems to be very long and tough. To mitigate this, we can use the well-known step-by-step method with gradual adjustments to the existing delivery pipeline.
This is an article from DZone's 2022 DevOps Trend Report.
For more:
Read the Report
Software firms have long relied on a DevOps approach to enhance agility and collaboration in software delivery. CI/CD pipelines automate processes in the software development lifecycle (SDLC) to enable seamless integration and delivery of new features. While CI/CD pipelines enhance software development through automation and agility, they involve integrating numerous tools and services, which can introduce security gaps. Identifying and remediating these security gaps is key to ensuring secure CI/CD practices. This article presents a general overview of what you need to know as you secure your CI/CD pipeline.
This is an article from DZone's 2022 DevOps Trend Report.
For more:
Read the Report
Continuous integration/continuous deployment (CI/CD) pipelines have matured from new forms of automation to mission-critical systems. DevOps teams rely on pipelines to deliver value to their customers by tightening developer feedback loops and standardizing processes. When a system becomes more valuable and important, it tends to increase in complexity. It must support more users, be more reliable, and perform, despite the increased load. Soon the CI/CD system built for one team has grown to support every business line in the firm.
This is an article from DZone's 2022 DevOps Trend Report.
For more:
Read the Report
What Is GitOps and Why Is it Important for an Organization?
GitOps is a model to automate and manage infrastructure and applications. This is done by using the same DevOps best practices that many teams already use, such as version control, code review, and CI/CD pipelines. While implementing DevOps, we've found ways to automate the software development lifecycle, but when it comes to infrastructure setup and deployments, it's still mostly a manual process. With GitOps, teams can automate the infrastructure provisioning process. This is due to the ability to write your Infrastructure as Code (IaC), version the code in a Git repository, and apply continuous deployment principles to your cloud delivery.
This is an article from DZone's 2022 DevOps Trend Report.
For more:
Read the Report
Continuous integration (CI) and continuous delivery (CD) are crucial parts of developing and maintaining any cloud-native application. From my experience, proper adoption of tools and processes makes a CI/CD pipeline simple, secure, and extendable. Cloud native (or cloud based) simply means that an application utilizes cloud services. For example, a cloud-native app can be a web application deployed via Docker containers and uses Azure Container Registry deployed to Azure Kubernetes Services or uses Amazon EC2, AWS Lambda, or Amazon S3 services.
This is an article from DZone's 2022 DevOps Trend Report.
For more:
Read the Report
DevOps is a hot topic that is quickly becoming the way of software development. It aims to promote development speed and reduce costs while increasing productivity and efficiency in your organization. DevOps is powered by automating your entire development, delivery, and operations processes. With continuous integration (CI) and continuous delivery (CD), you can do more with less, so it is beneficial to start implementing these concepts into your company as early as possible.
CI/CD pipeline refers to a series of sequential practices comprising Continuous Integration (CI) and Continuous Deployment and/or Continuous Deployment (CD). Commonly utilized by DevOps teams, the CI/CD pipeline is one of the most efficient methods to build, test and deploy code, largely via automation tools.
Leveraging CI/CD pipeline has been reliably provided to facilitate the construction and deployment of more updates (and better ones) to software. This is largely because successful CI/CD pipelines require consistent collaboration and honest implementation of Agile and DevOps principles.
Cloud operations are complex. There are a lot of reasons for this complexity, but in this post, I want to focus on how resources and services are managed in today’s clouds. Cloud today is oftentimes comprised of a large number of heterogeneous resources that have altogether different methods for managing them.
This diversity of resources is in large part the byproduct of cloud practices that predate infrastructure as code (IaC). Before automation and IaC, many companies would configure resources and services manually, without any alignment to best practices, based on internal processes that are unique to the organization. As companies evolved, and adopted IaC for codifying and managing cloud resources, this created a mishmash of services that are managed and unmanaged.
In recent years, DevOps has established itself as a formidable force in the software world. By bridging the gap between development and IT operations teams, DevOps has brought speed, efficiency, and quality to software development. It enabled IT businesses to adopt agile software delivery methodologies like Continuous Integration and Continuous Delivery (CI/CD).
However, despite gaining universal popularity, the road to successful DevOps adoption remained bumpy. Many organizations struggle to implement optimal automation across the software development lifecycle (SDLC), from build, integration, and testing to delivery and deployment. Consequently, harnessing the full potential of the CI/CD pipeline remained elusive. At this juncture, Jenkins has emerged as an indispensable tool to help DevOps teams achieve automation goals.
Introduction
The shift towards microservices has a direct impact on the testing strategies applied and has introduced a number of complexities that need to be addressed. In fact, microservices require additional levels of testing since we have to deal with multiple independently deployable components.
An excellent explanation of these concepts and the various levels of microservices testing is given by Martin Fowler in his Testing Strategies in a Microservice Architecture presentation. Let's have a look at the revised "test pyramid" from this presentation:
When it comes to delivering software through a DevOps model, the primacy of the platform is increasingly evident. DevOps platforms are multi-tenant, self-service oriented, developer-centric, and are an essential component of a multi-cloud strategy. They provide guide rails and standardized tools and technologies for developers to build, test, and iterate with ease. A core component that must not be neglected when operating a DevOps model, however, is resilience.
DevOps breaks down monolithic products into smaller value streams that can be delivered as independent cloud-based services. Once teams are set up to deliver under this model, it will be formalized through service level agreements (SLAs). To deliver against these, robust monitoring and alerting practices must be put in place. As with any DevOps practice, automation is the ultimate goal — and when it comes to monitoring and alerting, an AIOps platform is the gold standard.
Introduction
As the computing world continues to develop new processes for creating software, criminals continue to evolve their own techniques that exploit the flaws in those processes. DevOps is the latest trend in software development, and it is characterized by high levels of automation. More and more parts of the software development process can occur without human intervention which speeds up development. However, this is not without its drawbacks.
Less human involvement means less oversight from start to finish, and it also means more technologies to potentially exploit or abuse. Most of the risk involved is related to using sensitive information within automation, allowing for several ways to steal secrets. There are also things like code tampering to worry about. To keep your code and secrets safe, you should add the following security practices to your CI pipeline.
As more and more companies move to a multi-cloud strategy and increase usage of a cloud-native infrastructure, API providers are under a lot of pressure to deliver APIs at scale in multi-cloud environments. At the same time, APIs should follow each company’s security requirements and best practices, no matter the cloud platform. These reasons explain why many providers have such complex API authorization requirements.
Let's assume in a company that multiple teams from different lines of business are building and deploying APIs in the Azure cloud. Different teams use different technologies to build these APIs (e.g., Azure Functions, Node.js). A company might host applications that consume the APIs on the same network, such as a company's AWS account or external SaaS applications.
This week, we have news of a high criticality vulnerability on GoCD, a common open-source CI/CD system, allowing attackers to hijack secrets of downstream supply chains. There is also an excellent article on the journey of Raiffeisen Bank International toward full lifecycle API security, another article on how API security is hindering application delivery, and a report on the continued API sprawl by F5.
Vulnerability: Popular GoCD CI/CD Platform Vulnerability Disclosed
This week, SonarSource warned of a highly critical vulnerability in the common open-source CI/CD system, GoCD. The vulnerability could allow attackers to gain access to critical pipeline data, including secrets such as API tokens or credentials for downstream supply chain elements.
In the previous posting, we build a Spinnaker pipeline to pull images from Dockerhub to deploy to a Minikube cluster. In this article, we will build a pipeline that deploys to a second staging environment after waiting for the go-ahead from an approval step. Kustomize will, furthermore, be used to illustrate how Spinnaker utilizes its built-in kubectl command to manage configurations from one environment to the next.
Requirements
The hard yards have been done and it is time for play. Only Kustomize will be added to the soup. Do not despair should you not be familiar with it. This write-up serves as an excellent introduction to Kustomize.
Introduction
In the previous article, we installed Spinnaker on a Minikube cluster running on Windows 10. In this article, we will add GitHub as a data provider for a Spinnaker pipeline to continuously deploy a dockerized Spring Boot microservice onto the Minikube cluster. The pipeline will be triggered using a Cron job and can be templated so that all one's micro-services are automatically deployed to have a fully up-to-date local development environment at all times.
Requirements
An understanding of Spring Boot, Github, and Docker Hub is presumed. However, fall-back instructions will be given for those that want to follow a lighter track that pulls the Docker image from the author's registry. However, certain things like proper artifact binding might not work as expected should the full guide not be followed.
