To help you guys understand the nuts and bolts of this better, at our company we use Git repositories. These "repos" store each code change that our developers make. Each file change is versioned, so you have a really good record of who is making what changes. You can also revert changes easily, if needed. We then use Jenkins, which is an automation server. This is the tool that polls the repository for changes and then builds and deploys a new version to one or more servers. In practice, when a developer commits code to the repository (i.e. a dev repo) then Jenkins sees those changes and automatically builds a new version of the application. Any developer on our team can commit to the dev repo, and doing so creates a new dev build. This dev build is stored in its own folders (actually its own vm), and it creates a new set of tables in the database, so we have a fresh build to work with. All of our database changes are also scripted and stored in the same repo. This free for all dev repo is the only one that any developer can commit to. One of our team leads is then responsible for merging those changes into a stage repo. They then can manually trigger the Jenkins stage build, which then creates a new stage instance and database. The stage database includes more sample data, that the QA teams use to test. Assuming that looks good to us (and the client) we move that to pre prod. Again, only one guy on that team can do that, and it is after getting the green light from the client. The pre prod instance includes actual data (but SOC-2 required DID of personal data) so the client can do more realistic testing on actual data. Assuming the client and QA give the green light, prod is updated. This involves not only the lead developer, but also support from our Sys Admin. He needs to back up production first, confirm the integrity of those backups, and then run scripts to update the database scheme / tables if necessary. Sometimes an issue gets through the cracks and into production. In those cases, we test a hotfix in pre prod, and then if it passes muster we deploy to prod and then merge those changes back to dev and stage. This is a pain in the @#$ but the other option is impacting the user base by deploying rogue builds. The key is to control who can commit to what repository, which is easily configured within Git and Jenkins. These tools are super flexible, so any team can develop a process that fits their needs, culture, stakeholders, etc. We use this process, and I am not saying it is the best way to do it. But...

These guys are not following best practices. 

 

Edited March 22, 20251 yr by RobJC

15 minutes ago, Ianrivaldosmith said:

I am sorry but I can not help but laugh at that hahaha 

You are almost certainly right, but we can dream, right? 

15 minutes ago, Treetops45 said:

8.7GB update launched then said "Error" at the end & would not reload, so tried to get out via File Manager & now word not allowed S drive where MSFS 2024 is housed is not 'contactable'

What a word not allowed fiasco.

T45

some of us had this earlier, the current solution seems to be to opt out of the beta in the xbox app, then it seems to let you reinstall in the windows store... Had totally the same thing...

21 minutes ago, RobJC said:

To help you guys understand the nuts and bolts of this better, at our company we use Git repositories. These "repos" store each code change that our developers make. Each file change is versioned, so you have a really good record of who is making what changes. You can also revert changes easily, if needed. We then use Jenkins, which is an automation server. This is the tool that polls the repository for changes and then builds and deploys a new version to one or more servers. In practice, when a developer commits code to the repository (i.e. a dev repo) then Jenkins sees those changes and automatically builds a new version of the application. Any developer on our team can commit to the dev repo, and doing so creates a new dev build. This dev build is stored in its own folders (actually its own vm), and it creates a new set of tables in the database, so we have a fresh build to work with. All of our database changes are also scripted and stored in the same repo. This free for all dev repo is the only one that any developer can commit to. One of our team leads is then responsible for merging those changes into a stage repo. They then can manually trigger the Jenkins stage build, which then creates a new stage instance and database. The stage database includes more sample data, that the QA teams use to test. Assuming that looks good to us (and the client) we move that to pre prod. Again, only one guy on that team can do that, and it is after getting the green light from the client. The pre prod instance includes actual data (but SOC-2 required DID of personal data) so the client can do more realistic testing on actual data. Assuming the client and QA give the green light, prod is updated. This involves not only the lead developer, but also support from our Sys Admin. He needs to back up production first, confirm the integrity of those backups, and then run scripts to update the database scheme / tables if necessary. Sometimes an issue gets through the cracks and into production. In those cases, we test a hotfix in pre prod, and then if it passes muster we deploy to prod and then merge those changes back to dev and stage. This is a pain in the @#$ but the other option is impacting the user base by deploying rogue builds. The key is to control who can commit to what repository, which is easily configured within Git and Jenkins. These tools are super flexible, so any team can develop a process that fits their needs, culture, stakeholders, etc. We use this process, and I am not saying it is the best way to do it. But...

These guys are not following best practices. 

 

hey Rob, if I remember rightly and someone feel free to correct me, they use Perforce at Asobo. We do too at work, mainly because Github hits a hard limit when you have enormous amounts of game graphics and falls over. But yes, you are spot on. I was checking our files on the Dovetail games (our publishing partner) perforce only an hour ago for a new TSW5 project. Haven't used Jenkins yet but I know fellow gamedevs who do.

But yes, stuff slips through the cracks... This, though was a mighty big crack. I feel for the devs, I am sure they are mortified. I know many of the Asobo people and they are good people.

all the best

Jane

Edited March 22, 20251 yr by JaneRachel

I can confirm that by backing up the community folder and the local cache folder with the user.cfg I copied all files in the local cache folder down to the html's and copied and pasted all that over the new msfs 2024 install got me back in the saddle in no time and I didn't have to reinstall add-ons.  Salute to the trail blazers and the knowledge passed down.

 

Edited March 22, 20251 yr by jwhak

27 minutes ago, JaneRachel said:

some of us had this earlier, the current solution seems to be to opt out of the beta in the xbox app, then it seems to let you reinstall in the windows store... Had totally the same thing...

Prior to reading this I went into Xbox & fossicking around managed to finish/fix  the update & MSFS 2024 is now running, but all my Graphics settings & probably other settings [I haven't got through them all yet], have been changed.

Not particularly happy about having to retune the settings. 

T45

21 minutes ago, JaneRachel said:

hey Rob, if I remember rightly and someone feel free to correct me, they use Perforce at Asobo. We do too at work, mainly because Github hits a hard limit when you have enormous amounts of game graphics and falls over. But yes, you are spot on. I was checking our files on the Dovetail games (our publishing partner) perforce only an hour ago for a new TSW5 project. Haven't used Jenkins yet but I know fellow gamedevs who do.

But yes, stuff slips through the cracks... This, though was a mighty big crack. I feel for the devs, I am sure they are mortified. I know many of the Asobo people and they are good people.

all the best

Jane

Hi Jane, I haven't used Perforce in the past, but our projects don't have the massive size assets that a game like this would have. And yeah, I am sure the developers are upset about this. Lessons learned! Every time we have an issue, we go back to what was the root cause, and how can we avoid that one again. Life is a learning journey! I hope they can fix this one from happening again. 

3 hours ago, mobiel said:

Aren't there such problems with Steam?

Nope

Well, this was my experience about an hour ago so they have not fixed the issue.

I started MSFS2024 and the update began. It ended showing an error and 2024 would not start.

Ran ms store, went to my library and was able to finish the update.

Ran msfs2024 with no problem except that all my graphic settings had been reset and my community folder was empty. Control assignments were just fine.

I always keep a backup of community, exe.xml and usercfg.opt files.

Looking in current usercfg file, my Installed package locstion had been changed to the default rather than "F:MSFS2024" which I use.

I replaced the usercfg file and the exe.xml file and all was well. All my settings and my community folder were still there just not where the "updated" usercfg file thought.

All in all, the whoile process to get back to normal took ten minutes.

 

 

looking forward to watch  their faces in the next developer stream.

So are people with custom locations for their community folder unaffected by the wipe? Just need to reset the folder location?

2 minutes ago, vgbaron said:

All in all, the whoile process to get back to normal took ten minutes.

that's a real beta  tester!

53 minutes ago, Tuskin38 said:

Just need to reset the folder location?

no, my usercfg.opt got also replaced by a fresh, virgin version. like everything else in that directory after I had left the beta.

Edited March 22, 20251 yr by turbomax

24 minutes ago, Tuskin38 said:

So are people with custom locations for their community folder unaffected by the wipe? Just need to reset the folder location?

You are correct Sir.

So, for those fortunate that haven't launched msfs yet, because we traveling abroad.

Can this be avoided? As if it exit the SU2 beta prior launching msfs 2024?

Best,

Raul