Build Forge - Variable creation and scope
Currently I deploy code to a handful of servers. The same job runs on every server The issue I'm running into is that I have certain steps that loop in the event that a windows service does not start. If a service fails to start, I set one of the environment variables to 'N'. During the next iteration of the step I check the value, and determine whether or not to run the step again. Simple.
Thanks.
|
9 answers
Hello,
Yup that's it. Each time a server runs it sets a variable like BF = 1. Then when the next server runs it may have a BF value of 2. Thus switching it to BF = 2. But if that original server looks back at BF again later it says, "what the heck! return code 105 I quite!"
You could even go as far as to, at the end of the step put in something like .bset BF = 0 to reset the value to zero, but there is no for sure way to know some race type condition wont get in the way.
I don't know how deep down the whole you want to go. But you could do some really cool things here using a conditional step or my favorite the .drill. I mean BF has a million .commands that you can use to manipulate stuff.
Good Luck and I hope this helps
Thanks for using the forums!
|
|
I just posted about a .bset and I must of posted just before this or something.
Ahh ok. If this is the path you want to take. There is a problem with Referencing a variable inside a reference. This is what I mean by rabbit hole lol. See Below.
See this example.
STEP .bset env "Status_Deployment=_${GG_SERVER}"
EXEC .bset env 'Status_Deployment' = '_ten' (New Variable)
I get a value equal to ten. If I want to print that value or reference it. EXEC Performing variable expansion on command line SCRIPT echo _ten 3/6/14 11:47 AM EXEC start [C:@WITCHTRIALS] 3/6/14 11:47 AM EXEC _ten If I try to do it your way.
Does not echo. Meaning I can't reference it. The logic isn't there. Here is what you CAN do
.bset env "Ryan=Status_Deployment=${GG_SERVER}
.bset env "John="STATUS_COMPLETE"
Now I have two variables. I can reference them separately or together.
SCRIPT echo Status_Deployment_ten=STATUS_COMPLETE177 3/6/14 12:09 PM EXEC start [C:@WITCHTRIALS] 178 3/6/14 12:09 PM EXEC Status_Deployment_ten=STATUS_COMPLETE |
The dot-command you are interest in here is .tset
It does the same thing as .bset, but with a scope limited only to the thread-block in which it is executed.
Typically I see .tset used to set parameters in a threaded step that inlines a library.
If you wanted the information in the more tightly scoped variables to be available to other steps after the thread-block completes, then you would have to use the above discussed techniques to create individual variable names.
|
|
Hello,
If I understand right. You have a project. Say project A.This project is ran on multiple different agents. Meaning that if Project A associated with environment A. Would run on server 1. Settings in Environment A's would be set. Then when Project A associated with environment A runs on Server 2. the setting in Environment A would be overwritten to reflect that of server 2 not server 1.
Is that what you are describing?
If so. You could duplicate the project for both servers. So you have Project A and Project B. Associate Project A with environment A and Project B with environment B. Assign a selector to the Project A where it's suppose to run and one for Project B where it's suppose to run. These are separate projects and wont run in parallel. You could however create a and duplicate the steps in the project. Changing the environment at the step level for each step in the project. Then run all the steps in threaded. If you have the steps created, it's just a matter of copying those steps and changing the environment and selectors.
let me know if this helps or if I am way off base.
Thanks!
|
|
We have 9 servers(potentially more in the future) that require the same install. It would solve the issue potentially, yes, but it would also create more issues than it would solve. I also have a form that kicks off this job and can only kick off one Build Forge job per submission. So I'd have to submit 9 forms for each release as well besides creating a maintenance nightmare.
I appreciate the help, but still surprised that a product that is designed to deploy code on many servers never addresses this issue with an elegant solution. Let me know if you think of anything else.
Thanks!
|
|
Hello,
I understand your concerns. If I were to do what you are doing. I would create a single project with 9 steps. This way your single form submission would kick off a single project and run everything. Than at the step level and not project level. I would assign a different environment. Since each step would run on a different server, I would make all the steps threaded. This way one form submission would kick off the project which does everything on all nine servers at once.
Why?
1. This is very scalable. Add a server, remove a server by adding/remove 1 step. I can also just check a step and it wont run the next time the project launches.
2. Scalability again by making it really easy to add functionality over time. Say my boss wants 5 of the 9 servers to report back the status of a running Web Server. I can create a library with a single step. Then just add that step as an inline to the 5 servers. Then if he comes back and says I need a status of running Web Server and disk space, but only disk space on three of the 5. I can create a single step as a library and add that to the 3 of the 5 servers.
4. There is additional functionality with this setup too. I can take advantage of the join in threaded steps. Let's say I had 9 servers now but 30 later. Well maybe network latency or whatever is not allowing me to run these at the same time. I can thread steps 1-15 add a join on step 15 and it will kick off 15 and then stop and wait until all are finished before kicking off the next 15.
3. Troubleshooting would be much easier since each step is isolated. Especially good for if you leave or are on vacation and someone else takes over. It's very easy to see what is happening form a support standpoint.
4. I see very low maintenance with this. If each server uses the same script. It would appear that you can change the script and it changes all the servers. There would be no reason to have to edit the steps. If something changes in the step, you would have to reproduce that for all the steps. Depends on how often the steps change I suppose to consider this a negative.
At least from my perspective, someone who isn't trying to do what you are and has not attempted it yet. This is how I would approach it. Just an opinion. I have seen environments where every user patches things to work for them and as time goes on things get very very complicated, redundant and become a support nightmare. Build Forge capabilities are limitless really. Just depends on how creative you wanna get. Which I try to stay away from.
|
|
So is that the real culprit? That all 9 servers are running using the same environment and hence use the same pool of declared variables?
|
|
Actually, I tried this the other day:
.bset env "Status_Deployment_${BF_SERVER}=STATUS_COMPLETE"
which actually saved a unique variable in BF like this
Status_Deployment_<SERVERNAME>
However, I couldn't figure out how to reference the variable.
This was how I tried to reference it:
${Status_Deployment_${BF_SERVER}}
However Build Forge resolved that as:
${Status_Deployment_<SERVER>} and wouldn't actually find the variable. Am I doing something wrong in trying to reference it? I was wondering if there were any escape characters that I could use to make this work.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.