Answers: <p>I've done this before, normally in the form of having a <code>/.well-known/info</code> endpoint available on every microservice that then returns a JSON payload with what's in it:</p>
  <pre><code>{
      &quot;service_name&quot;: &quot;token_exchange&quot;,
      &quot;server_id&quot;: &quot;RD1717628373&quot;,
      &quot;commit_hash&quot;: &quot;f72a28&quot;,
      &quot;branch&quot;: &quot;feature/content-security-policy&quot;,
      &quot;version&quot;: &quot;v2.8.12-f72a28-prerelease1&quot;,
      &quot;dependencies&quot;: [
          {
              &quot;id&quot;: &quot;db&quot;,
              &quot;type&quot;: &quot;database&quot;,
              &quot;endpoint&quot;: &quot;db.mysite.com&quot;
          },
          {
              &quot;id&quot;: &quot;service&quot;,
              &quot;type&quot;: &quot;microservice&quot;,
              &quot;endpoint&quot;: &quot;RD661872834&quot;
          }
      ]
  }
  </code></pre>
  <p>I then have a cron job and custom dashboard that queries all of the services that it knows about and then walks the dependency tree to add any newly added dependencies.</p>
  <h1>Considerations</h1>
  <ol>
  <li><strong>Agree a Standard</strong> - The first step is to agree on a standard across services that you want to report on, then get them implemented.  It's hard to show the value of this kind of thing when only 1% of your estate implements it.</li>
  <li><strong>Start Small</strong> - I created a command-line interface that went and queried it at first.</li>
  <li><strong>Security</strong> - It could be an attack surface from an information security perspective, so test it and possibly add some authentication component to it and turn it off in production.</li>
  </ol>
  
Answers: CC BY-SA 4.0
Answers: 2020-07-01T21:28:34.860Z
Answers: Thanks - We already have endpoints to display what packages and versions are installed so that's not an issue.  For clarification, it's the same application installed among the various QA environments, so the same package names but with different versions.  Different projects going live at different times and all must be merged back at some point but, while they are in testing, they will be in different environment.
Answers: DaveTX
Answers: CC BY-SA 4.0
Answers: 2020-07-01T17:06:59.977Z
Answers: 2020-07-01T17:06:59.977Z
Answers: Richard Slater
Body: <p>We work on multiple java web projects going on at the same time and those are all being tested on several different QA environments.  I'd like to show on our support portal what projects are in what environments without having to manually update it all the time.  I was thinking of some way to tag the builds so I could just query tomcat or those linux servers themselves and show the results.  The tags would be something like &quot;August Release&quot;, &quot;Project 1&quot;, &quot;Project 2&quot;, etc.. Has anyone done something similar?  I'm looking for different options.</p>
  
Tags: <jenkins><git><java><tomcat>
Title: What's in THIS environment?
UserDisplayName: DaveTX
ThreadText: # What's in THIS environment?
  
  (Asked by: username_0 on 2020-07-01)
  
  We work on multiple java web projects going on at the same time and those are all being tested on several different QA environments. I'd like to show on our support portal what projects are in what environments without having to manually update it all the time. I was thinking of some way to tag the builds so I could just query tomcat or those linux servers themselves and show the results. The tags would be something like "August Release", "Project 1", "Project 2", etc.. Has anyone done something similar? I'm looking for different options.
  
  **Tags:** jenkins, git, java, tomcat
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2020-07-01. Score: 3
  
  I've done this before, normally in the form of having a `/.well-known/info` endpoint available on every microservice that then returns a JSON payload with what's in it:
  
  ```
  {
      "service_name": "token_exchange",
      "server_id": "RD1717628373",
      "commit_hash": "f72a28",
      "branch": "feature/content-security-policy",
      "version": "v2.8.12-f72a28-prerelease1",
      "dependencies": [
          {
              "id": "db",
              "type": "database",
              "endpoint": "db.mysite.com"
          },
          {
              "id": "service",
              "type": "microservice",
              "endpoint": "RD661872834"
          }
      ]
  }
  
  ```
  
  I then have a cron job and custom dashboard that queries all of the services that it knows about and then walks the dependency tree to add any newly added dependencies.
  
  # Considerations
  
  1. **Agree a Standard** - The first step is to agree on a standard across services that you want to report on, then get them implemented. It's hard to show the value of this kind of thing when only 1% of your estate implements it.
  2. **Start Small** - I created a command-line interface that went and queried it at first.
  3. **Security** - It could be an attack surface from an information security perspective, so test it and possibly add some authentication component to it and turn it off in production.
  
  > **Comments:**
  > **username_0**: Thanks - We already have endpoints to display what packages and versions are installed so that's not an issue.  For clarification, it's the same application installed among the various QA environments, so the same package names but with different versions.  Different projects going live at different times and all must be merged back at some point but, while they are in testing, they will be in different environment.  
  
  ---
  
  