Build engine approach?
-
So, over the years, the place where I work has slowly, grindingly improved their s/w processes. In 2020, the mission is to get build engines going for all current and recent products. Right now, we're all laptop sensitive, code releases being built on individual developer laptops. So, naively, I ask IT to spin up a few virtual machines on our development server. This simple request morphs into.. oh never mind, let's say it got complicated. So, let's say you have N products you need to do regular builds for. I'm of the opinion that unless the products are very close in their nature and build tools, they each get their own VM. In my mind, it limits the coupling between products and build requirements. I'm sure I'm going to have to explain this approach. Thoughts and opinions?
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
That should not require explanation.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
You would think. Every time I ask for a VM, it turns into a research project. I mean, it's trivial. But I'm just here to help.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
So, over the years, the place where I work has slowly, grindingly improved their s/w processes. In 2020, the mission is to get build engines going for all current and recent products. Right now, we're all laptop sensitive, code releases being built on individual developer laptops. So, naively, I ask IT to spin up a few virtual machines on our development server. This simple request morphs into.. oh never mind, let's say it got complicated. So, let's say you have N products you need to do regular builds for. I'm of the opinion that unless the products are very close in their nature and build tools, they each get their own VM. In my mind, it limits the coupling between products and build requirements. I'm sure I'm going to have to explain this approach. Thoughts and opinions?
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
What color should it be? Nasal fitment?
-
So, over the years, the place where I work has slowly, grindingly improved their s/w processes. In 2020, the mission is to get build engines going for all current and recent products. Right now, we're all laptop sensitive, code releases being built on individual developer laptops. So, naively, I ask IT to spin up a few virtual machines on our development server. This simple request morphs into.. oh never mind, let's say it got complicated. So, let's say you have N products you need to do regular builds for. I'm of the opinion that unless the products are very close in their nature and build tools, they each get their own VM. In my mind, it limits the coupling between products and build requirements. I'm sure I'm going to have to explain this approach. Thoughts and opinions?
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
That's the problem with professional IT. They understand nothing of development workflow... I consider myself lucky, to be my own IT...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
-
That's the problem with professional IT. They understand nothing of development workflow... I consider myself lucky, to be my own IT...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
Truth. I get the 1000 yard stare when I tell them development will be managing the VMs. The local IT is all goodness. I've worked with them long enough that they understand what I'm trying to do. It's the corporate IT Borg that give me trouble. Example: me: "I'm sorry, 2 of the virtual machines will need Windows Xp." IT: "Sorry, we don't use that anymore. We don't support it." me: "Well the development tools for the product that our biggest customer uses needs Xp." IT: "Can't you try Windows 10?" me: "No, the tools don't work." IT: "But we don't know how to support Xp anymore. It's a security risk." me: "It's okay, development will manage it. Besides, we're not surfing the web here. Honest." IT: "But...." me: "I'll have my director call your director... What we've got here is failure to communicate." 3 months later....
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
So, over the years, the place where I work has slowly, grindingly improved their s/w processes. In 2020, the mission is to get build engines going for all current and recent products. Right now, we're all laptop sensitive, code releases being built on individual developer laptops. So, naively, I ask IT to spin up a few virtual machines on our development server. This simple request morphs into.. oh never mind, let's say it got complicated. So, let's say you have N products you need to do regular builds for. I'm of the opinion that unless the products are very close in their nature and build tools, they each get their own VM. In my mind, it limits the coupling between products and build requirements. I'm sure I'm going to have to explain this approach. Thoughts and opinions?
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
How about one VM running Docker, and then run your builds in Containers configured for the product? Basically, bring the machine to the VM.
"Time flies like an arrow. Fruit flies like a banana."
-
How about one VM running Docker, and then run your builds in Containers configured for the product? Basically, bring the machine to the VM.
"Time flies like an arrow. Fruit flies like a banana."
This. Admittedly I'm late to the Docker party but it really has a ton of advantages. No need to ensure consistency between environments for the product across the organization since that's handled by using a consistent image; it makes IT's life easier because as far as they're concerned they've just got a bunch of containers; etc. It is a significant workflow overhaul and requires some training on use though, so that's a pretty big hurdle to overcome to get approval unfortunately.
-
So, over the years, the place where I work has slowly, grindingly improved their s/w processes. In 2020, the mission is to get build engines going for all current and recent products. Right now, we're all laptop sensitive, code releases being built on individual developer laptops. So, naively, I ask IT to spin up a few virtual machines on our development server. This simple request morphs into.. oh never mind, let's say it got complicated. So, let's say you have N products you need to do regular builds for. I'm of the opinion that unless the products are very close in their nature and build tools, they each get their own VM. In my mind, it limits the coupling between products and build requirements. I'm sure I'm going to have to explain this approach. Thoughts and opinions?
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
charlieg wrote:
So, let's say you have N products you need to do regular builds for. I'm of the opinion that unless the products are very close in their nature and build tools, they each get their own VM. In my mind, it limits the coupling between products and build requirements. I'm sure I'm going to have to explain this approach.
this, plus Matthew Dennis's comment - Docker/Containers .. if you dont go Docker/containers for the builds, at least use Docker/containers for the testing so you get a clean test environment every time, unless you keep a 'gold' image for the combinations and clone it when needed, then destroy the clone at the end of the run (we did this on a particular cloud test system). As to 'very close in their nature and build tools', we had separate build machine(s) for language basically, C++, C# etc - even then, our C++ product had a large dependency on a third party GUI library that occasionally gave us issues, more with the paths and such
-
How about one VM running Docker, and then run your builds in Containers configured for the product? Basically, bring the machine to the VM.
"Time flies like an arrow. Fruit flies like a banana."
I'll have to read up on that, I was just happy to be able to get to the VMs. Sounds useful. Thanks for the suggestion.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
That's the problem with professional IT. They understand nothing of development workflow... I consider myself lucky, to be my own IT...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
