Environmentalists…

[#1]

So we baked environment support into the Activity Feed a long time ago, but never had a chance to wire up the necessary sources or build a UI toggle.

Until now! :D

We've turned on staging and are collecting deployment events from Bitbucket, GitHub and GitLab. Let us know which event types you associate with environments and also which environments you'd want to explore with this tool.

[Robin]

Very nice! Can't wait to try it out! :) 

A great addition to Compass I can think of would be "versions" as well. Ones that you can set as "in production" (multiple) and also use in the dependency tree. 

As an example, for the "production" environment I am releasing "1.2.0" right now, but in a month we'll have "1.3.0" and "2.0.0" live at the same time. Being able to see which applications are relying on which version (in production) would be fantastic to be able to phase out versions (faster). 

Thanks for the current update though, I think it might prove very useful! 

Will there be a way to use the Jira Release feature in combination with this? (Or my feature request?)

Thanks again!

[Garyl Paras]

Awesome!
What are the environment mappings in GitLab for staging and production?

[Brent Vierling]

This is great!  Is there any plans to get an integration for Azure DevOps?

[Dave Mathijs]

@Andrew Freedman The title of your post really came across like a click bait, you fooled me there. 😉

[Andrew Freedman]

@Garyl Paras we trust the environment information GitLab provides. They've got some info in their docs which clarify the heuristic they use.

[Garyl Paras]

@Andrew Freedman  the GitLab document you provided does not provide much information about all the environment name mappings supported by Compass.
In your documentation on GitHub, there's a section where all mappings are mentioned. However, in your GitLab documentation, the environment mappings are not mentioned.

Are the environment name mappings for GitHub the same as those for GitLab?

Also, is it possible to modify these environment mappings like making 'uat' map to 'staging'?

Thanks,

[Katie Silver]

Thanks @Robin for your comment! 

Noted your requests for versions. It's definitely something we've discussed. Do you see it more in use around things like Libraries, or do you envision that for any component type? 

Re: releases, it's on our radar, but not roadmapped yet. I know the team working on it has some really cool features in store and hopefully we'll be able to collaborate with them soon! 

[Josh Campbell]

Hey @Garyl Paras we need to update the GitLab app to have the same mappings as GitHub, I just cut a ticket for that. Right now the mapping is very basic for GitLab: you must use either "production" or "staging" for the environment to get picked up by Compass. Obviously not ideal, we will expand it to look like the GitHub mapping you linked. Will take a few weeks to get this out, cheers.

[Robin Keet]

Hi @Katie Silver

Thanks for your reply :) 

I can see it being useful for any component type. 

A current actual use-case I have is that in about 2 months I have planned to release a version 2.0 of a service of ours. That will have Backwards Compatibility (BC) breaking changes. At the same time 1.x will continue to be live for an X-period (a quarter, maybe 2) until it is removed. 

Having versions attached to services, application, libraries, etc. will allow using Compass to see which products have been migrated, and which are lacking behind.

Next to seeing easily if an outdated version might need to stay live a bit longer, it might also help to flag unattended products or (s)low-performing teams.

Another use case would be to push teams to migrate away from a certain version of a certain package/product if it was flagged as a security risk. As an example, a new SVE gets published for product X version a.b.c with the issue fixed in a.b.d, then being able to quickly identify which are using a.b.c is also very valuable. 

And lastly, having versions available in Compass might also help boost adoption of Compass. Because a combined setup of VCS (Bitbucket/Gitlab/Github/?) with Compass, with Compass API to push data, could cause developers to automate the "import everything from our VCS into Compass" to generate the dependencies programmatically. The next automation step being to tie it into Releases (Jira or VCS or both) to automatically update the dependencies and map those with versions. 

Taking that last bit yet another step, having Releases and dependencies with versions automated, you could even tie it into monitoring and logging solutions to automatically attach reported problems with both Jira Issues, as well as the version in Compass to easily track / monitor / display issue per Release. 

Thinking out loud and ahead. 

So yea, looking forward to versions :) 

One last suggestion for dependencies in Compass: it would also be great to be able to categories dependencies of a Component as being "product dependency" or "development dependency". Example real-life use-case: we use PhpUnit in local development and deployed development environment, but this dependency is not included in staging and production deployments. This difference is managed in `composer.json` files in PHP projects where you put things in the `require` section for running the application as a whole and the `require-dev` section to add things onto the application for development only. 

[Katie Silver]

Thanks so much @Robin Keet , this is a super helpful picture of how you're working. We will definitely take this under consideration. Keep an eye on the community for updates, as always! 

[Josh Campbell]

@Garyl Paras hey there circling back on the GitLab environment name mapping. It actually looks like we are relying on GitLab's own "environment tier" naming system for our app: https://docs.gitlab.com/ee/ci/environments/index.html#deployment-tier-of-environments. It looks like you can declare your own mapping using the GitLab CI file https://docs.gitlab.com/ee/ci/yaml/index.html#environmentdeployment_tier. We're just looking for the "tier" so as long as your environment name is properly mapped to a tier in GitLab we'll see the events in the right tier when we call their API. Let me know if you've tried this and it's still not working as expected.

[Steffen Opel _Utoolity_]

So we baked environment support into the Activity Feed a long time ago, but never had a chance to wire up the necessary sources or build a UI toggle.

Now that you have that toggle @Andrew Freedman, is there a reason why it is still restricted to production and staging and doesn't offer all environment types supported by the API, i.e. including 'testing', 'development', and 'unmapped'?

Notably these match the environment types in Jira Software, and I assume deliberately, so why not just surface them all like the Jira Software deployments view does?

The current limitation also does not align with the 3 environment types hard wired for both Forge environments (which uses 'development') and Bitbucket Pipelines deployments (which uses 'testing').

[David Berclaz]

If you are an Environmentalist, you may like our new stickers 😄

Write me if you need one!