Answers: <p>Instead of trying to watch, how about working together to define a scripted way of defining environments that is scm managed.  Having the configuration for deployment in the SCM insures they are always consistent and allows the collaboration and communication between team members about the ways they want to work.  </p>
  
  <p>There are many tools that can be used to script the configuration of the system level as well as the application level definitions.  Using this kind of definition based environment configuration not only helps with the development level, but then also helps with the deployment to later stages capabilities.  </p>
  
  <p>This would also facilitate the communication between team members a fundamental principle of DevOps.   </p>
  
Answers: CC BY-SA 4.0
Answers: 2018-08-12T16:09:10.243Z
Answers: 2018-08-12T16:09:10.243Z
Answers: Rosalind Radcliffe
Answers: <p>I agree with @Tensibai and rather using a tool I would suggest to talk with your team members about the tools they use rather than sniffing their system.</p>
  
  <p>If one would use a tool to spy other systems then that is not aligned with DevOps. DevOps is about getting rid of silos. Using a tool for "secretly" monitoring colleague system is a contradiction. Imagine that the developers would know that such a tool is used, then silos will be created again and that is not DevOps. DevOps is about building bridges between team members and departments, e.g. Ops, Dev and QA.</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-03-03T00:59:37.767Z
Answers: 2018-03-03T00:59:37.767Z
Answers: 030
Answers: <p>Optionally, you could consider vortual workbench like Che (in case it is mature enough for your purposes, can't judge on this.)
  And, such actions must be definitely in sync with privacy protection law and colleagues informed.
  I see a use case where it is not spying but rather establishing standards (a good workshop topic).</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-03-03T14:01:17.153Z
Answers: 2018-03-03T14:01:17.153Z
Answers: Ta Mu
Body: <p>I would like to start collecting parameters from local developer environments on my team, such as to see how they configure their properties files (not in source control), what directory they use as their application root, where they have this and that software installed etc.</p>
  
  <p>So I was envisioning having a script that each would run daily and which would post that data to some web service within some application that does this kind of stuff within the DevOps realm -- team management etc. Is there such an app for local developer management, just like Jenkins does builds or Chef does deployments?</p>
  
  <p>Ideally, I would go into this console and get an idea of how each developer on my team has their environment configured without that developer letting me see their laptop, provided that, of course, my data collection script includes all the relevant parameters.</p>
  
Comments: CC BY-SA 3.0
Comments: 2018-01-03T17:23:00.870Z
Comments: That sounds like an intrusion into devs privacy and sounds borderline at best unless devs agree with a tool 'monitoring' them. Out of that point that's an inventory management, ocsng with glpi could fit your needs in the various inventory tools
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2018-01-03T17:27:06.810Z
Comments: it's not intrusion of privacy, they would know their local config is collected for management purposes
Comments: amphibient
Comments: CC BY-SA 3.0
Comments: 2018-01-03T17:31:34.453Z
Comments: Various countries laws prohibit this when it comes to track how someone configure its workstation when they are allowed to, so yes it is an intrusion even if accepted/acknowledged by the targeted population. I know it is widely done and understand the point but I think you're going backward collecting various Config instead of bullding one and deploying it.
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2018-03-03T00:57:47.253Z
Comments: `Ideally, I would go into this console and get an idea of how each developer on my team has their environment configured`. You could also ask them.
Comments: 030
Tags: <configuration-management>
Title: Tool to collect developer environment parameters
UserDisplayName: amphibient
ThreadText: # Tool to collect developer environment parameters
  
  (Asked by: username_0 on 2018-01-02)
  
  I would like to start collecting parameters from local developer environments on my team, such as to see how they configure their properties files (not in source control), what directory they use as their application root, where they have this and that software installed etc.
  
  So I was envisioning having a script that each would run daily and which would post that data to some web service within some application that does this kind of stuff within the DevOps realm -- team management etc. Is there such an app for local developer management, just like Jenkins does builds or Chef does deployments?
  
  Ideally, I would go into this console and get an idea of how each developer on my team has their environment configured without that developer letting me see their laptop, provided that, of course, my data collection script includes all the relevant parameters.
  
  **Tags:** configuration-management
  
  > **Comments:**
  > **username_1**: That sounds like an intrusion into devs privacy and sounds borderline at best unless devs agree with a tool 'monitoring' them. Out of that point that's an inventory management, ocsng with glpi could fit your needs in the various inventory tools  
  > **username_0**: it's not intrusion of privacy, they would know their local config is collected for management purposes  
  > **username_1**: Various countries laws prohibit this when it comes to track how someone configure its workstation when they are allowed to, so yes it is an intrusion even if accepted/acknowledged by the targeted population. I know it is widely done and understand the point but I think you're going backward collecting various Config instead of bullding one and deploying it.  
  > **username_2**: `Ideally, I would go into this console and get an idea of how each developer on my team has their environment configured`. You could also ask them.  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_3 on 2018-08-12. Score: 4
  
  Instead of trying to watch, how about working together to define a scripted way of defining environments that is scm managed. Having the configuration for deployment in the SCM insures they are always consistent and allows the collaboration and communication between team members about the ways they want to work.
  
  There are many tools that can be used to script the configuration of the system level as well as the application level definitions. Using this kind of definition based environment configuration not only helps with the development level, but then also helps with the deployment to later stages capabilities.
  
  This would also facilitate the communication between team members a fundamental principle of DevOps.
  
  
  ---
  
  ### Answer by username_2 on 2018-03-03. Score: 2
  
  I agree with @username_1 and rather using a tool I would suggest to talk with your team members about the tools they use rather than sniffing their system.
  
  If one would use a tool to spy other systems then that is not aligned with DevOps. DevOps is about getting rid of silos. Using a tool for "secretly" monitoring colleague system is a contradiction. Imagine that the developers would know that such a tool is used, then silos will be created again and that is not DevOps. DevOps is about building bridges between team members and departments, e.g. Ops, Dev and QA.
  
  
  ---
  
  ### Answer by username_4 on 2018-03-03. Score: 0
  
  Optionally, you could consider vortual workbench like Che (in case it is mature enough for your purposes, can't judge on this.)
  And, such actions must be definitely in sync with privacy protection law and colleagues informed.
  I see a use case where it is not spying but rather establishing standards (a good workshop topic).
  
  
  ---
  
  