Product Update

ReleaseIQ Product Update: December 2021

Our December release includes:

  • JIRA integration
  • New Project and Productivity dashboards
  • Pipeline as Code
  • Deployment verification using APM tools

Our new capabilities address many of product leadership’s top of mind issues such as:

  • Lack of visibility into the progression of new features from commit to deployment
  • Desire to modernize the software delivery, but no time to rip and replace existing tools
  • Too much time and effort pulling data and normalizing reports across all the tools, pipelines, and teams.

JIRA Integration (Track and Update Projects from Commit to Deployment)

ReleaseIQ now provides integration with JIRA to track individual tasks/stories/Epics to see what environments they are in.  Using the integration, the development teams using JIRA can gain visibility into managing feature development & issue tracking. This feature provides a near real-time trend of estimates with deployments across environments.  It is usually extremely hard to track JIRA issues from CI to CD, especially across different tools.  With ReleaseIQ’s new capability this is very straightforward.

JIRA Dashboard

New Project and Productivity Dashboards

Finally, we have our next-generation productivity and project dashboards which give you the data and insights to keep your team, including the leadership, happy.  Working across all the tools that ReleaseIQ integrates with, some samples are below:

DevOps Dashboard

Dora Metrics

Pipeline as Code

One of the core values of ReleaseIQ is the no-code drag and drop pipeline composer.  While this is extremely valuable to teams building pipelines from scratch or importing pipelines from other tools, there are often times where the number of pipelines makes this method of pipeline creating tedious. In those cases, import/export pipelines as code are more desirable.  Pipeline as code is part of a larger “as code” paradigm, wherein the pipeline definitions are represented as code that can be versioned in a source repository and tracked.  The ReleaseIQ Pipeline Composer now supports both visual and code representation of a pipeline.  With this method, the pipeline representation as code is simple & easy to understand declarative syntax.  We use YAML as it is a common language for configuration.  

Pipeline as Code

Deployment Verification

Implementing automatic deployment verification is an important principle of continuous DevOps pipelines.  Deployment verification where an observability tool is used to track the health of the new application or service and changes are made allowing for rollback if an issue arises in the production environment. ReleaseIQ has implemented the capability to integrate with New Relic and App Dynamics to provide performance events to any step in the pipeline to be used for deployment logic.  Additionally, ReleaseIQ can now send notifications to the observability tool to ensure that teams that use those tools are aware if a deployment occurred. 

Putting all of this together, ReleaseIQ aids developers, test, DevOps, management, and leadership with unprecedented pipeline orchestration, automation, and insights to increase productivity and drive faster deployment. 

Sign up for a briefing and demo for your team here.

Developer Pipelines

Introduction:

As part of coding, developers usually create a feature branch out of the main branch and implement the required features. It involves building the code, deploying it to a local environment, and testing it manually to make sure it has no bugs. In highly complicated features, this involves more than one developer working in parallel in the same feature branch.

Developer’s challenges:

As a developer, in the pre-merge process, I have gone through this multiple times. Apart from spending a lot of effort on writing code, I have spent a lot of time populating the data in the local environment, and need to tweak the automation test scripts to run them according to environment configurations. It involves manual testing to be done with assumptions about real-time use cases, to make sure that source code will run as expected in the actual environment.

As the testing happens mostly in the local environment, the feature would usually function well. Even though the feature looks good during quick testing, this may be due to not having proper data in local infrastructure. There could also be a mismatch in infrastructure-related configuration, and so on;  this may lead to breaking the actual team’s test environment, which affects continuous integration of other developer’s features. It can completely block the QA team from testing other features.  A small flutter of the butterfly’s wings can have effects greater than we developers realize or intend.

Additionally, every time we do code changes this requires the developer’s effort to build and deploy the source code to the local box. Due to manual intervention, some of the environment-related configurations can go wrong.  This is a process just waiting to blow up.

As multiple developers may work in parallel in a feature branch, a developer won’t have visibility on what has been done by another developer. It would be difficult to troubleshoot, if the feature doesn’t work as expected, and spot the bugs, whether it arises from other developers’ code.

In some instances, it may be required to involve the QA team to run the tests on complicated features. As the code from different developers goes into the test environment, it would be difficult to identify the features implemented and filter out the test scripts to be executed. It may result in re-running the passed test cases again and again, and it would be a never-ending process until the sprint is completed.

It requires a lot of manual configuration changes to be done in the local environment.  If we think we can avoid local environment changes, it is not practical to expose the infrastructure-related information like build/deploy scripts to developers. It may lead to everyone playing around with the environment, and it may end up affecting the script quality and stability of the environment and will end up in a mess.  I have seen this happen.

On the other hand, if the scripts are being controlled by the deployment team, each and every developer needs to contact the deployment team to push each and every simple feature to the dev/test environment. It will affect the productivity of both developers and DevOps engineers. It will introduce delays in deployment lead time.

Nowadays, optimizing the release process has become the new normal. As there are CI pipelines available to push the source code from the previous environment in the workflow to production, visibility of where the source code stands has begun to be clearer. It is also necessary to have the same visibility before merging the source code from the feature branch to the main branch. It involves troubleshooting the failures in an earlier stage from the feature branch itself and provides visibility to other developers and the QA team about whether the code is ready for testing, or if the feature is still under development.

ReleaseIQ’s Pre-merge (Developer) pipeline:

Based upon real customer use cases and challenges in providing the visibility of pre-merged source code, ReleaseIQ has built a pre-merge pipelines capability. It is implemented end-to-end by focussing on the developer’s needs and specific problems as they go through deploying their code to the dev/test environment. Developers need control over creating the pre-merge CI pipelines and at the same time to not have access to the merged pipelines configured in the CI tool which contains critical information. As a first step, the ReleaseIQ admin decides which CI tools can be accessed by developers, and also which job/pipeline can be accessed by developers. In this way, the jobs which have access over critical/high environments can be restricted from developers.

Developers commit their source code to source control systems (like Github, BitBucket, GitLab, SVN, Perforce) and then the ReleaseIQ pipeline immediately begins creating the build, then deploys it to the test environment and runs the necessary tests configured by the developer. Upon successful testing, developers can immediately raise pull requests, to the approver. On approval, the ReleaseIQ pipeline covering end-to-end will start to deploy to real-time environments like stage, prod etc.

Use case: Build/Deploy/Test the feature and create pull request

Pre-merge pipeline creation in ReleaseIQ

CI tool setup:

Admin/Devops can do one time set up of CI tools (Jenkins), and provide CI tools access to developers only with limited jobs which would not impact the critical environment like PROD.

Setting up CI tools for developer pipeline

Pipeline creation:

Admin can create the pipelines in their CI tools, which will have access only for dev/test environments. Developers will be given access to those jobs in CI tool settings.

Pipeline creation by Developers:

Developer Pipeline

Developers can create their own customized pipelines, which can build their source code, deploy it and run tests. Once tests are successful, developers can approve their pipeline which creates pull requests and assign it to mentioned approvers.

Pipeline execution:

Pipeline Execution

The Commits screen in ReleaseIQ product provides E2E visibility of pipeline execution and developers can have complete information at each commit level.

Pipeline Execution

Troubleshooting:

If the pipeline fails, without CI tool access, developers will be able to access the logs and identify the bugs and fix it on their own. It doesn’t require access to Dev machines, or manual intervention of the DevOps/admin.

Pipeline Failure

On a single click of the failed pipeline stage, developers will be able to root cause the issue and fix it.

Troubleshooting Logs

If this is interesting, then check out our ReleaseIQ for Jenkins edition and get to work on your developer pipelines.

End-to-End Release Pipelines for Kubernetes Apps using ReleaseIQ

Introduction

Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications to increase the productivity of the developers. Containers are a good way to bundle and run your applications. In a production environment, you need to manage the containers that run the applications and ensure that there is no downtime. Kubernetes applications can be deployed in the cloud and to Kubernetes clusters hosted in other environments. By using the containerized applications we can have testing environments similar to production which can catch issues earlier in the process.. Kubernetes deployments allow you to build application services that can run in multiple containers, schedule those containers across a cluster, scale those containers, and manage the health of those containers over time.  Kubernetes has transformed the application development model.

Continuous Integration (CI)

Continuous Integration (CI) is a process that allows developers to integrate work into a shared environment; for example pushing code to development quite frequently as needed,  This enhances collaborative development. Frequent integration helps dissolve silos, reducing the size of each commit to lower the chance of having an issue in the pre-production or production environments. CI workflow starts from listening from the source code management (SCM) system, to building  the source code and deploying to a shared development environment  and then running any Integration tests.

Continuous Delivery/Continuous Deployment (CD)

Continuous delivery extends the continuous integration process by deploying builds that pass the integration test suite to a pre-production environment.This makes it straightforward to evaluate each build in a production-like environment so that developers can easily validate bug fixes or test new features without additional work.

Once a build passes automated tests in a pre-production environment, a continuous deployment system can automatically deploy the build to production servers.This enables teams to release new features and bug fixes instantly.

Importance of End-to-End Pipeline

The advantage of the end-to-end pipeline in ReleaseIQ is the developer, project manager, team lead, and DevOps team can have visibility from check in of code until it is being deployed to production. Key is the visibility to debug the issue when there is a failure on any step. The deployment to a specific environment can be tested thoroughly using automated or manual tests. Deployment control can be given to the application owners whether to proceed with deployment or to reject the deployment. Team members can backtrace performance and infrastructure issues as well.

Single Microservice E2E Pipeline

We can use ReleaseIQ to deploy a single microservice from SCM to production. The workflow consists of listening from SCM, building the source code, uploading the binary to a build repository, deploying to a test environment, running an automated test for deployment verification and if the verifications are successful, deploy to the production environment.

Use Case #1 – Using ReleaseIQ Internal Capabilities

The workflow for the use case is listening from SCM, building source code using Maven or Gradle, pushing Docker image to a build repository, and deploying to Kubernetes using the Helm via ReleaseIQ.

Prerequisites:

  1. Create Product, Team, and Component for the Use Case.
  2. Configure the Source Control Management in Settings.
  3. Configure the Build Repository in Settings.
  4. Configure the Environment with Appropriate Kubernetes Cluster Configuration.
  5. Verify the Helm configuration files with these samples.

Configure the Internal Build Configuration as below in Build Step:

  • Choose Build Tool Name as Maven
  • Select Maven Version from drop-down
  • Enter the goal of Maven
  • Select the Java version
  • Select the Build Repository name and File Repository.
  • If you want to Scan the Deliverable select the checkbox
  • If you want to fail the pipeline if there is any vulnerability, select the fail pipeline checkbox

Kubernetes Build Set up

Configure the Internal Deployer Configuration as below in Deploy Step:

  • Select the Environment which is configured with Kubernetes cluster
  • Select the Deployer tool Name as “Internal Deployer Tool”
  • Choose the endpoint of the cluster
  • Select Deployment Type as “Helm”

Kubernetes Deploy Step

Choose Add Helm Configuration:

  • Select the SCM, Repository, Branch name, and path which contains the Helm Deployment files.
  • If you have multiple YAML files for Deployment add those file names in the Deployment files text box
  •  Enter the Namespace where we want to deploy the Application.

Add Helm Configuration

The overall End-to-End Pipeline will look like this:

End to End Pipeline

The pipeline execution will look like this:

Pipeline execution

Use Case #2 – Using Jenkins for push to build repository

The workflow for the use case is listening from SCM, building source code, pushing Docker Image to a Build Repository using Jenkins, and deploying to Kubernetes using Helm via ReleaseIQ.

Prerequisites:

  1. Create Product, Team, and Component for the Use Case.
  2. Configure the Source Control Management in Settings.
  3. Configure the Jenkins CI Tool in Settings.
  4. Configure the Environment with Appropriate Kubernetes Cluster Configuration.
  5. Verify the Helm configuration files with these samples.
  6. Archive the Build Location and Build ID in the Jenkins Job/Pipeline.

Configure the Build Step as Below:

  • Select the Jenkins CI Tool configured in the Build Tool Name.
  • Select the Jenkins Job or Jenkins Pipeline that build and Push Docker image to Build Repository.

Kubernetes Build configuration

Configure the Internal Deployer Configuration as below in Deploy Step:

  • Select the Environment which is configured with Kubernetes Cluster
  • Select the Deployer tool Name as “Internal Deployer Tool”
  • Choose the endpoint of Cluster
  • Select Deployment Type as “Helm”

Kubernetes Deployment configuration

Choose Add Helm Configuration:

  • Select the SCM, Repository, Branch name, and path which contains the Helm Deployment files.
  • If you have multiple YAML files for Deployment add those file names in the Deployment files text box
  • Enter the Namespace where we want to deploy the Application.

Helm Configuration

The Overall E2E Pipeline will look like this:

End-to-End Pipeline

The Pipeline Execution will look like this:

Pipeline Execution

Multiple Microservice CI/CD E2E Pipeline:

There are many scenarios where we have multiple microservices for an application. These microservices could be dependent or Independent. We may want to deploy the microservices one by one if they are independent and we want to deploy multiple services together if they are dependent. Also we want to deploy the microservices together at a scheduled time or we may want to get some approval before the deployment. ReleaseIQ can easily implement these scenarios and many others.

Use Case:  The workflow for the Use case is two CI pipelines connected to a CD Pipeline.

CI Pipeline #1:

Listening from SCM, Build Source code using Maven or Gradle, Push Docker Image to a Build Repository and Deploy to Kubernetes using Helm via ReleaseIQ. Configure the CI pipeline same as single microservice Use Case #1 and add a pipeline connector to connect to the CD pipeline.

CCI Pipeline

CI Pipeline #2

Listening from SCM, Build Source code Push Docker Image to a Build Repository using Jenkins Tool and Deploy to Kubernetes using Helm via ReleaseIQ. Configure the CI pipeline same as Use Case #2 and add a pipeline connector to connect to the CD pipeline.

CI Pipeline

CD Pipeline

Prerequisites:

  1. Create Product, Team and Component for the Use Case.
  2. Configure the Source Control Management in Settings.
  3. Configure the Build Repository in Settings.
  4. Configure the Environment with Appropriate Kubernetes Cluster Configuration.
  5. Verify the Helm configuration files with these samples.

Configure the Internal Deployer Configuration as below in Deploy Step:

  • Select the Environment which is configured with Kubernetes Cluster
  • Select the Deployer tool Name as “Internal Deployer Tool”
  • Choose the endpoint of Cluster
  • Select Deployment Type as “Helm”

CD Pipeline

Choose Add Helm Configuration:

  • Select the Linked CI Pipeline Name as CI Pipeline #1
  • Select the SCM, Repository , Branch name and path which contains the Helm Deployment files.
  • If you have multiple yaml files for Deployment add those file names in the Deployment files text box
  •  Enter the Namespace where we want to deploy the Application.
  • Click Add new and follow the above steps for CI Pipeline #2.

Helm configuration

The CD Pipeline looks like below:

CD Pipeline

The Pipeline Execution will look like this:

Pipeline Execution

For more information on our Essentials for Jenkins click here.

Adding CI Pipelines and Continuous Testing with Spinnaker CD Pipelines by using ReleaseIQ Platform

Application architectures have gone through a huge change over the past 5-10 years. Prior to unicorn companies building out scale out infrastructure, the major application pattern was monolithic apps sitting in physical and then virtual environments.  These applications (and their underlying infrastructure) needed care and feeding, updating and refactoring.  This all created a confusion of configuration states and status.   With the introduction of the new wave of cloud first companies and their applications came the paradigm shift toward immutable architectures where the entire application was redeployed over the existing one.  Configuration for both the application and the infrastructure environment became a matter of code.  This new cloud native architecture could be set up to run in any cloud, executing in portable containers laying the groundwork for this new model.  CI/CD changed along with these trends and orchestration of pipelines for dozens of code commits each week or even day required new models, especially in the deployment arena.   This blog highlights one of the key players in this new arena, Spinnaker, and how the ReleaseIQ platform integrates with Spinnaker to compose, integrate, execute, and manage the issues around these pipelines.

Spinnaker and Continuous Deployment

Spinnaker is an open source, multi-cloud continuous delivery (CD) platform for releasing software changes with high velocity and confidence. Created by Netflix and now used by hundreds of teams over a million deployments. Spinnaker creates deployment pipelines that run the integration and system tests, spin up and down server groups, and monitor your rollouts.

Spinnaker provides application deployment features to construct and manage delivery workflows. Below is the typical pipeline for continuous delivery workflow:

Spinnaker Pipeline

Source: https://spinnaker.io/concepts/#pipeline

The pipeline is the key deployment management construct in Spinnaker. It consists of a sequence of actions, known as stages. You can pass parameters from stage to stage along the pipeline. Pipelines can be started manually or can be configured to be automatically triggered by an event, such as a CI job completing, artifact appearing in the registry, CRON schedule or stage in another pipeline.

Spinnaker Integration with ReleaseIQ

The ReleaseIQ platform supports the integration of external tools to orchestrate the full process of CI, continuous test and CD.   Examples we already integrate with are Jenkins, CircleCI, Bamboo and Spinnaker. You can integrate Spinnaker with ReleaseIQ and orchestrate the CI/CD process pipeline from developer commit, test, other custom steps through deploying the code into an environment such as staging or production. Below are the three key use cases of using ReleaseIQ with integration of Spinnaker continuous delivery workflow along with other tool chains to bring end-to-end visibility and insights.

Use Case #1: ReleaseIQ CI and Spinnaker CD

In this use case, ReleaseIQ provides the continuous integration capability that will build the source, deploy, test and promote the qualified package to build the repository. In addition, the ReleaseIQ platform can bring the Spinnaker CD pipeline that can connect to the end of a CI pipeline.

ReleaseIQ Spinnaker Pipeline

Use Case #2: Jenkins CI, QA Test, Promote Build and then Spinnaker CD

In this use case, Jenkins CI is used by the development team, Spinnaker is used by the DevOps team for CD. ReleaseIQ provides the glue between CI and CD to bring end-to-end visibility. This is another great example of how two distinct tool chains with multiple teams can be integrated using the ReleaseIQ solution.  There is no need for specific teams to change what works.   Just input the external pipelines into ReleaseIQ and you get coordinated orchestration and instant visibility across those tools.

Jenkins Spinnaker Pipeline

Use Case #3: Using Bamboo & Jenkins CI, ReleaseIQ QA and then Deploy to Staging/Production through Spinnaker CD

In this use case, Bamboo & Jenkins CI are used by two different development teams and Spinnaker CD is used by the DevOps team. ReleaseIQ provides end-to-end visibility by orchestrating the multiple tool chains. In the example below, Once CI is done, the QA team can build the new package, qualify it through tests & promote it for deployment using Spinnaker.

Spinnaker CD

Dashboard:

ReleaseIQ platform provides a consolidated dashboard for users to see the status across all the pipelines. Below is a snapshot of the pipeline summary for the above 3 use cases.

Spinnaker Dashboard

Let’s now discuss how you can set up the ReleaseIQ system to allow you to run the above use cases.

ReleaseIQ Settings

In ReleaseIQ you can configure the Spinnaker tools in the Settings Screen. In the Deployment section of Settings you configure Spinnaker.

Spinnaker Settings

Enter the name of the Spinnaker tool, choose the Tool Type as Spinnaker, enter the Tool URL & API Token credentials of your Spinnaker setup.

After saving you can see your Spinnaker tool on the right table with the status of integration connection in ReleaseIQ.

Embedding a Spinnaker Pipeline in the ReleaseIQ Composer

In the Pipeline screen you can embed your Spinnaker CD pipeline into a larger pipeline context.  After building CI pipeline, choose External Pipeline for CD. In the Tool Name dropdown you will see Spinnaker which was configured in the Settings page previously. Then select the appropriate configuration settings based on the Spinnaker CD pipeline. In the below example, ReleaseIQ provides the CI pipeline & then connects it to Spinnaker CD pipeline.

Spinnaker Pipeline

Running a Pipeline with an Embedded Spinnaker Pipeline

In the ReleaseIQ UI you can see the last execution of the pipeline. In the component filter choose the component and you will see the pipeline displayed graphically. All the stages and job information of the pipeline containing Spinnaker will be displayed along with the status of execution.  If the pipeline has failed the Spinnaker job will be highlighted in red.

Spinnaker Execution

Logs for the Complete Pipeline

You can explore the  logs of each job in the Spinnaker pipeline.. When you select the completed (Success/Failed) Job of Spinnaker you can see the full logs.

Spinnaker Logs

This blog on Spinnaker integration with the ReleaseIQ platform shows how a DevOps team that uses Spinnaker for deployment can up level their CI/CD pipeline to integrate other best of breed tools. There is no reason to have both a highly automated deployment pipeline disconnected from a highly functional CI front end.  Adding continuous test to the middle only serves to create that truly best of breed integration.   No need to build a “leaky” pipeline.  ReleaseIQ enables multiple teams to gain the value of that unified orchestration, visibility and insights for troubleshooting.

Want to learn more about our integrations and how to configure, run and gain unified visibility for all your pipelines, schedule a demo here or view our product brochure.

Integrating Atlassian Bamboo Pipelines with ReleaseIQ Platform

It is a common use case where an organization has multiple products and projects that use different CI/CD tools, such as Jenkins and Atlassian Bamboo. The DevOps goal is to orchestrate all these pipelines with a unified platform, gain visibility into the status of these pipelines and to provide dashboards and metrics to increase insights to resolve failures. All this can speed up release cadence and increase team productivity. Your teams get the value of visibility and dashboards across the different tool chains. No need to change what works today. The ReleaseIQ platform provides exactly those needs for developers, testers, product managers, DevOps and the leadership team.

Introduction

Atlassian Bamboo is a popular option for many teams to perform CI/CD. It provides automated build, testing of software source code status and updates on successful/failed builds. Bamboo has two features: build and deploy. You can build via a Bamboo build plan and save the deliverables as an artifact and then the deploy project will take the deliverables and deploy to the environment as configured.

Here is the Bamboo Configuration hierarchy. It states the execution workflow of a Bamboo Build project Plan.

Bamboo Integration with ReleaseIQ

The ReleaseIQ platform supports the integration of external tools to orchestrate the full process of CI, test and CD. Examples we already integrate with are Jenkins, CircleCI, Spinnaker and Bamboo. You can integrate Bamboo with ReleaseIQ and orchestrate the CI/CD process pipeline from developer commit, test, other custom steps through deploying the code into an environment such as staging or production. Below are the three key use cases of using ReleaseIQ with integration of Bamboo’s CI and CD plans along with other tool chains to bring end-to-end visibility and insights.

Use Case #1: Bamboo CI, QA Test and then ReleaseIQ CD

In this use case, Bamboo CI is used by the development team. CI functionality can be extended to QA and Ops teams using ReleaseIQ. ReleaseIQ provides the ability to introduce additional steps that can integrate both CI and CD pieces together. In the below example, Once CI is done, QA team can pick up the package, qualify it through additional tests & approve it for deployment.

Use Case #2: Bamboo CI and then Spinnaker CD

In this use case, Bamboo CI is used by the development team, Spinnaker is used by the DevOps team for CD. ReleaseIQ provides the glue between CI and CD to bring end-to-end visibility. This is another great example of how two distinct tool chains with multiple teams can be integrated using the ReleaseIQ solution. There is no need for specific teams to change what works. Just input the external pipelines into ReleaseIQ and you get coordinated orchestration and instant visibility across those tools.

Use Case #3: Using Bamboo & Jenkins CI, QA Test and then Deploy to Production through ReleaseIQ CD

In this use case, Bamboo & Jenkins CI are used by two different development teams and ReleaseIQ CD is used by the Ops team. ReleaseIQ provides end-to-end visibility by orchestrating the multiple tool chains. In the example below, Once CI is done, the QA team can pick up the package, qualify it through additional tests & approve it for deployment. This is a great example of how two distinct tool chains with multiple teams can be integrated using the ReleaseIQ solution. 

Let’s now discuss how you can set up the ReleaseIQ Platform to allow you run the above use cases.

ReleaseIQ Settings

In ReleaseIQ you can configure the Bamboo tools in the Settings Screen. In the CI sections of Settings you configure Bamboo.

Enter the name of the Bamboo tool, Choose the Tool Type as Bamboo, enter the Host, username and password credentials of your Bamboo setup. 

After saving you can see your Bamboo tool on the right table with the status of integration connection in ReleaseIQ.

Embedding up a Bamboo Pipeline in the ReleaseIQ Composer

In the Pipeline screen you can embed your Bamboo Plan into a larger pipeline context. Configure the source code management tool of your choice and for the build choose External Pipeline. In the Tool Name dropdown you will see Bamboo which was configured in the Settings page previously.

In Project choose the Bamboo Project and in Plan choose the desired Project Plan.  You can see that all the Bamboo stages and jobs are represented in ReleaseIQ. Add the other steps needed for the pipeline like Deploy, Tests and approval from ReleaseIQ to provide the extended functionality.

Running a Pipeline with an Embedded Bamboo Project and Plan

In the ReleaseIQ UI you can see the last execution of the pipeline. In the component filter choose the component and you will see the pipeline displayed graphically. All the stages and job information of the pipeline containing Bamboo will be displayed along with the status of execution.  If the pipeline has failed the Bamboo Job will be highlighted in red.

Provide Logs For The Complete Pipeline

You can explore the  logs of each job in the Bamboo pipeline.. When you select the completed (Success/Failed) Job of Bamboo you can see the full logs. Viewing the log, you can see it contains all the logs of the tasks that were configured inside the Bamboo job.

Interested in more Atlassian Integrations?  We already integrate with Bitbucket and JIRA, stay tuned for future blogs on those topics.  


Want to learn more about our integrations and how to configure, run and gain unified visibility for all your pipelines, schedule a demo here or view our product brochure.