-3

In my current organisation, we have several different build environments (like toolset etc.) which are needed for compiling the code of different modules within the same product. I found this a big mess where every engineer, in order to build their codebase, first has to go through the mundane task of setting up their dev machine confining to that module's requirements.

E.g. recently I had to jump to a different module to code their interface that interacts with mine. In order to do this, I had to spend considerable time to actually create a dev environment where the code can at least get compiled. I think this is pretty messy and often leads to wasting time doing stupid things.

Is this really a good practice that other companies follow as well? I was wondering if I should write scripts that can do this automatically. Is there any other way as well, like having a common build setup that acts as superset for all modules (though it might have some extra stuff in itself)?

Improve this question
3
  • 1
    You haven't provided enough specific details about your problem to make this answerable. Naturally, if something can be automated in a cost-effective way, it's better to automate it. Commented Nov 10, 2017 at 2:45
  • 2
    Is it "good practice"? Obviously not. Do other companies "follow [this practice] as well"? Obviously yes, because there are lots of companies at not everyone of them has optimized their processes to the degree they should. "I was wondering if I should write scripts" - well, who is primarily responsible for the build environments and has an interest in getting things done more effectively? That is the person you should ask the question, not us. Commented Nov 10, 2017 at 6:58
  • 1
    ... FWIW, the real question you should have asked yourself, however: which options exist to make this more smooth (ok, such a question would be closed here on SE, since the community does not like list-of-things questions). I suggest you start talking to the team, I am sure there are others who had to fight the same battle in the past. Here are the measures I would try: first: reduce the necessary toolset, if possible. Second: clear and up-to-date documentation how to set up the environments. Third: scripts & automation for setting up the environment. Commented Nov 10, 2017 at 7:10

1 Answer 1

Reset to default
2

You could try virtualization. Set up VMs with different build environments and appropriate version control system setup. Then, when you need to switch environments, it is only a matter of shutting down one VM and bringing up another one.

The obvious downside is that you need extra disk space for different VMs, and they would have to have less RAM than your physical workstation. However, since these VMs are purely development oriented, they should not be too big, as they would not have usual overhead of various documents that you typically keep on your physical workstations.

Improve this answer
3
  • 1
    IMHO that's a last resort if there is no chance to clean up the mess otherwise. It would not be my first choice, however (but YMMV). Commented Nov 10, 2017 at 10:24
  • I do agree with you that this is the last resort, but in some cases it is the only choice you have. In my company, we have a very complex product that spans over several different versions, and on each version, we have many project customizations, each of which is a project of its own, so VMs are the only solution for us. Commented Nov 10, 2017 at 10:49
  • 1
    Or you could just use Docker containers, rather than entire VMs... Commented Nov 10, 2017 at 14:01

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.