Jenkins is the stepping stone for any organization looking to implement a CICD pipeline and move away from a legacy software delivery process. However, Jenkins started as a tool to reduce errors caused due build issues and code failures. This tool later formed the center of a framework called automated continuous integration that checked for code failures before it was committed for deployment. Therefore, we can term Jenkins as an automation tool used by software development teams looking to bring continuous integration into their delivery process. It was initially built on Java and was targeted towards Java projects. …
Almost all IT teams across the world engaged in software development need to deliver software changes and updates iteratively.
In doing so they adopt the CI/CD process to streamline their software delivery. But while promoting a release artifact from one stage to the next, they employ a manual risk evaluation process for making judgments which is both time-consuming and costly.
This not only dilutes the effectiveness of the CI/CD process but also contravenes the underlying philosophy of continuous delivery that mandates a fully automated delivery workflow a.k.a. CI/C pipeline to speed up software delivery.
An OpsMx customer, a leader in the world of networking and cybersecurity solutions found it challenging to reduce build failures, and reduce the lead time to diagnose the root cause and fix them.
To mitigate this problem they had introduced a centralized build service for all developers that would facilitate a team of SREs for faster diagnosis and triage of errors and improve recovery rates.
Although this proved as a costly option the build error rates were still too high and time-consuming due to manual intervention. The customer was using Jenkins as the CI tool.
They chose the OpsMx Autopilot…
A regional telecommunications company envisioned a digital transformation initiative that would redefine their retail customer experience.
They wanted to stream new OTT content to their subscribers and revamp their existing ordering process for a unique voice and data plans. But their outdated software delivery process was slow in pushing new UI/UX changes to their website.
They used Bamboo CI for software delivery, which was not scalable and required them to maintain many custom scripts for deploying microservices. Another humongous challenge was establishing a secure connection to the RedHat OpenShift platform where they needed to deploy their applications.
The verification process…
An online web portal, a market leader in their business domain needed to modernize their software delivery due to intense competition.
Their complex hybrid IT infrastructure included both microservice-based applications and monolith legacy systems. Using only Jenkins, plugins and custom scripts for their CI/CD processes they were only able to achieve a fraction of their targeted number of deployments.
So they were looking for mechanisms that could help them achieve a higher frequency of software updates and reduce faulty deployments. …
Spin CLI is a command-line interface client application popularly used to create and manage Spinnaker applications, pipelines, pipeline-templates-as-a-code, projects, and canary configs etc.
But if you are using a Spinnaker instance where the Identity Provider (IDP) is x.509 certificate authority (ca) and x.509 certificates are used for Spinnaker authentication, Spin CLI clients are not able to access Spinnaker. But Spin CLI can be configured with x.509 to authenticate calls against Spinnaker.
Read our blog “Expose x.509 enabled Spinnaker API endpoints for Spin CLI access” to know more how to configure the Spin CLI for x.509 authentication in order to access Spinnaker.
Spinnaker is an open-source multi-cloud continuous delivery platform for releasing software changes with high velocity and speed.
OpsMx Enterprise for Spinnaker (OES) is an enterprise-ready distribution of open-source Spinnaker that comes integrated with a variety of extensions aimed at faster and easier Spinnaker adoption, increasing the number of target application environments and managing the Spinnaker lifecycle.
The default OES is packaged with OpsMx Autopilot that adds intelligent visibility across Spinnaker CI/CD pipelines and reduces the risk of a new software release through automated validation, governance, and policy compliance.
OES can be installed in Microsoft Azure VMs an on-demand, scalable cloud…
Canary deployment is a release deployment strategy often used for Spinnaker deployments where a new release version is deployed alongside the stable running version.
It is exposed to a small subset of the end-users and then the canary version is evaluated against the baseline (a copy of current deployment) to find out if the new release is stable and ready to be rolled out.
Kayenta is the Spinnaker microservice that is responsible for enabling canary deployments in Spinnaker and performing automated canary analysis.
We can integrate application monitoring (APM) tools like Prometheus with the Spinnaker to provide us comprehensive performance…
Kayenta is the Spinnaker microservice that is responsible for enabling canary deployments in Spinnaker and performing automated canary analysis. Canary deployment is a release deployment strategy where a new release version is deployed alongside the stable running version.
It is exposed to a small subset of the end-users and then evaluated against the baseline (a copy of current deployment) to find out if the new release is stable and ready to be rolled out. The application config in Spinnaker has the configuration option to activate canary config and canary reports on Deck.
Kayenta supports monitoring tools like Stackdriver, Prometheus, Datadog…
Modern software delivery calls for closer collaboration between people, processes, and technology. CI/CD pipelines resulted from the DevOps best practices where the need for faster, safer, and reliable software was addressed by iterative and incremental release cycles.
A CI/CD pipeline is a visual representation of the automated steps needed to create an integrated seamless delivery workflow. It is created by joining all the stages of Continuous Integration (CI) and Continuous Delivery (CD) like code check-in, build creation, testing, and deploying to production. An automated event-based trigger can automatically set off a pipeline or else, it can also be triggered manually.
OpsMx transforms software delivery, enabling you to deploy changes at unequaled scale and speed.