2

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.

Improve this question
4
  • 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
    – Tensibai
    Commented Jan 3, 2018 at 17:23
  • it's not intrusion of privacy, they would know their local config is collected for management purposes
    – amphibient
    Commented Jan 3, 2018 at 17:27
  • 2
    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.
    – Tensibai
    Commented Jan 3, 2018 at 17:31
  • 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.
    – 030
    Commented Mar 3, 2018 at 0:57

3 Answers 3

Reset to default
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.

Improve this answer
2

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.

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.

Improve this answer
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).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.