memphis-iis / mofacts

8 stars 1 forks source link

Drill trial feedback broken on production #1377

Closed imrryr closed 10 months ago

imrryr commented 10 months ago

This is why I only wanted to push mofacts once only to production. I knew the quizzes worked then, but in the meantime, the 3 additional deployments have introduced a change so there is no feedback at all now. We need to lock in production to a working version for the quizzes ASAP. Then we need to get staging running for everything for the experiments, confirm the quizzes run, then update production.

JRustyHaner commented 10 months ago

@imrryr I'm on it

JRustyHaner commented 10 months ago

@imrryr it's taken care of. I apologize for the stress.

The reason why production had to be changed is that the recent changes requested to the skip button for your quizzes had to be pushed to staging (we never push code to the production branch). Other recent changes, for the loadbalancer had to be pushed to staging for the same reason.

Because the quiz changes were needed on the production server, it was required to push the staging branch to the production server. The production branch has not been changed since we last made a release, which was some time ago in November. Once this staging version is satisfactory to you, we can, of course push it to the production branch.

imrryr commented 10 months ago

That's not what I'm referring to I think. I'm referring to the multiple updates of mofacts production yesterday. Only the first one was necessary for the quizzes with skipstudy. The later changes were not intended for production and were not necessary I think since they were for bugs unrelated to the quizzes. @JRustyHaner

imrryr commented 10 months ago

I could be getting the timing wrong, and it was logical that you thought I wanted to get the loadbalancer running on production also, but really getting production working for the quizzes was my goal and I figured that particular build in that issue had quiz skipstudy working on staging, so it would work on production. I'm also sorry for the stress. I think we need to talk more about the procedures here at the meeting. I'd prefer to see the production branch match the production server. Also, I want to talk about putting me in the code review process since I think I can contribute. We must also be careful never to treat the production as another staging server. While bug fixes can always be deployed to staging, production should not be deployed except with confirmation from myself, please, since classes or experiments may depend on a specific build that has been tested, and new bug fixes may introduce new issues that break the expected capabilities of the desired build. @JRustyHaner

JRustyHaner commented 10 months ago

@imrryr Thanks. We can talk about code review processes if you like. Basically @MegaGeese or I test the code for deployment, specifically if the code works and it fixes the issue. We don't actually meet. If we find something that could break the code, we comment it in the pull request, otherwise we approve the merge of the code. We generally ask ourselves if it fixes the issue at hand and do a cursory look if it will break anything else. However, unless we run every possible case for that change, we can miss something. That's where the old saying comes from: "Fix one bug, cause another".