Can we expect more flexible environment handling for the activity feed soon?

[Steffen Opel _Utoolity_]

Given there's a dedicated 'Environment' column in the activity feed, and your sneak peak into "new event types and timeline view" within Kelvin's excellent recent update on Compass and our journey so far, I realize that this is likely in the works already, just to point out the impact of the current environment naming constraint:

We are using parallel Bitbucket Pipelines production environments with custom names to differentiate various flavors of our artifacts, e.g. 'prd-jira', 'prd-confluence', prd-compass' for a semantically cross-product Forge app, so the strict deployments activity limitation on Bitbucket environments with a name rather than a type 'production' results in our deployment activity not showing up in Compass at all (it works as expected for another service where the environment is indeed called 'production').

Can we expect Compass to differentiate environments by type rather than just the name in the near future?

[Andrew Freedman · Accepted solution]

Hi Steffen,

Thanks for sharing your experience with our environments model.

Our intent is to filter based on the environment type, not the name — exactly as you're describing actually. There could be a bug here that you've run into so hopefully we can reproduce it.

If I set up a quick test and add three prod environments (albeit as a serial pipeline rather than in parallel):

pipelines:
  branches:
    master:
      - step:
          name: One for Jira
          deployment: prd-jira
          script:
            - echo "Jira deployment"
      - step:
          name: One for Confluence
          deployment: prd-confluence
          script:
            - echo "Confluence deployment"
      - step:
          name: One for Compass
          deployment: prd-compass
          script:
            - echo "Compass deployment"

It seems to be working okay — but you're getting a different result from your setup?

(Also, we're starting things off with a focus on production environments, but we certainly do have plans to enrich our handling of non-prod environments over time.)

— Andrew

[Steffen Opel _Utoolity_]

Thanks for looking into this and the detailed response Andrew, much appreciated.

I've just been able to get our (parallel) pipeline setup working as well w/o any related changes, so this has most likely been an insufficient test matrix and/or diagnosis on my part:

• I might e.g. have been looking at several months old deployments in another project that had never been ingested into Compass and then drawing the wrong conclusion from the phrasing "Compass reads the events from the pipeline only where the value of the deployment keyword is set to production".

Either way, everything works as expected now :) - I look forward to the envisioned enrichments of the activity feed view!

[Andrew Freedman]

No problem at all — this tells me that we can make improvements to our docs, so really glad you reached out.

[Adam]

@Andrew Freedman - I have a similar question, which I'm happy to create a new question or discuss on a call.

Is there a thought to or a suggestion on how to track activities, using some of the existing frameworks for Bitbucket/Jira/Compass, for using self hosted Jenkins Pipelines and multiple client deployments (e.g. AWS Accounts)? Each client deployment would be comprised of a set of 3 environments (e.g. Dev, Test, Prod) where each environment/stack would have a collection of services, components, etc.

There are metrics that which are important holistically across all "instances" of a component but from a ITSM Support perspective, we need to be able to track, support, triage activities, incidents, performance, etc. per client.

We're already able to populate all the deployments for a given Jira Issue with Jira's OOB CI/CD Integrations (https://support.atlassian.com/jira-software-cloud/docs/integrate-your-deployment-pipelines-with-jira/) and wonder how to leverage the economies of scale here vs writing a lot of custom code to populate things.

Thanks!