<< Back to Programming Forum   Search

Posts 1 - 9 of 9   
Strategy for promoting code to production: 2024-09-16 21:44:41


Tread 
Level 58
Report
I have a folder on my computer. It has a git repository of lua code for a WZ mod, with the remote repo on GitHub. In mod development, I created a dev single-player mod and gave it the path to the folder on my computer. After testing locally, I created a multi-player mod and gave it the url of my GitHub repo.

I ran a few games. Fizzer approved. Now my mod is running in a number of games that I and others have created. All is going well.

To make an enhancement, I created a develop branch. I tested my changes locally. Now I want to test in multi-player.

Here is where I would like some strategy advice.

- Cowboy way is to merge develop to master and reload my mod. Danger of crashing all the games running the mod.

- Preferred way is to create another "staging" mod (that will never be sent to Fizzer for approval). Give it the path to the develop branch (not possible)

- Probably the way everyone is doing it (other than the cowboy way), is to not only create a "staging" mod on WZ, but also create a "staging" repo on GitHub.

It looks WZ will only accept the main branch URL for GitHub.

Thanks for any insight anyone may have on promoting changes to production.
Strategy for promoting code to production: 2024-09-16 22:44:27


Just_A_Dutchman_ 
Level 60
Report
what kind of modifications did you make?
Do you have a repository link?
Strategy for promoting code to production: 2024-09-16 23:09:16


Tread 
Level 58
Report
Hi thanks!

https://github.com/treadman/allow_guard_to_be_killed

master branch is what is currently in production
- merely kills the army standing guard

develop branch is what I added
- gives the option to the game creator to make the now empty territory neutral

I am concerned that if I push it to production, Mod.Settings.goNeutral will not be defined for games already started.
Strategy for promoting code to production: 2024-09-17 08:48:19


TBest 
Level 60
Report
Since you added a setting, then yes, it will indeed be nil for already created games.

In fact, maybe even for new games, if people use saved templates. So you can't count on "Client_SaveConfigureUI " being called for new games.

Many ways to do it, but somehow you need to account for it being nil. Maybe just a " if nil, then equal false" at the top of the relevant files. ( Or dump dump it in a file and function " GetGoNeutral() " and require it where needed , if you mind the code duplication)


If you had added alot of settings, I would have suggested making a new mod, and unpublishing the current one ( just putting it here for completness).

Edited 9/17/2024 08:53:27
Strategy for promoting code to production: 2024-09-17 08:54:43


JK_3 
Level 63
Report
You can just always give it a default value in the Server_AdvanceTurn.

Normally you would do that with:
local mySetting = Mod.Settings.MySetting or myDefaultValue
but that doesnt work with booleans.

For a boolean value, you can just let LUA falsify the nil for you:

if (nil) then
  -- this doenst run
else 
  -- but this does
end

if (false) then
  -- this doenst run
else 
  -- but this does
end

if (true) then
  -- this runs this time
else 
  -- and this doesnt run
end

Or if you need to do some more advance logic with it that requires you to have a true/false variable, you can use:

local mySetting = Mod.Settings.MySetting 
if (mySetting == nil) then
  mySetting = true -- or whatever default you want
end


Edited 9/17/2024 09:00:37
Strategy for promoting code to production: 2024-09-17 15:38:54


Tread 
Level 58
Report
I have this for advance turn:
if Mod.Settings.goNeutral ~= nil and Mod.Settings.goNeutral == true then
 -- make it neutral --
I'm hoping that games started prior to the update without the setting, will not break here.

I'll do it this way: Create a new mod for staging that I will delete when done testing. Do the same in GitHub. Start a game using the staging mod and the staging repo. After running a couple turns, update the staging repo with the changes, and see if the game breaks. If all is good, I can be comfortable doing it to the production mod. Then delete the staging stuff.
Strategy for promoting code to production: 2024-09-18 21:49:45


Tread 
Level 58
Report
Thank you everyone for helping me test!

In conclusion, it may be overkill, but I feel it was safest to create a clone of the repo, set up a temporary mod for staging the update, start up a few games, and then do the update there. If the running games keep running, feel comfortable doing the same thing to the public mod.
Strategy for promoting code to production: 2024-09-19 00:15:35


Just_A_Dutchman_ 
Level 60
Report
it is the best practice imo, although it is a bit of work indeed xD
Strategy for promoting code to production: 2024-09-19 00:17:52


Just_A_Dutchman_ 
Level 60
Report
I always try to think of all the bits I would like to add to a mod and add those good enough before fully releasing it. But yeah, you can find yourself almost always in a situation where you did not think of something
Posts 1 - 9 of 9