I have been participating in this project for many months now and have stuck with it despite numerous challenges. I have continued to participate because I see great potential for this project and I have a communication project that I want to develop a plugin for. There is one fundamental flaw to what I see is its future success and I believe it is relatively easy to address.
This became more evident to me with the rollout of ver 7 and a review of the forums. I have been involved with numerous development projects over the years and the ones that worked had one thing in common, thorough regression testing and a measured and controlled rollout. That’s not to say that weren’t problem just that they were minimal and did not dramatically alter the consumers anticipated functionality.
I encourage the developers to not rollout version upgrades or patches for that matter on the production branch until the total effect of their impact can be assessed and tested within development. What I experienced over the last week with version 7 indicates that this construct is not being followed here. Production should be almost bullet proof and should not really experience the troubles we had this week with integration and a simple bench update command. I am also very concerned about the calculation issues that have been showing up this week in the forums in regards to accuracy. For all of us that support this product its accounting integrity must be sacrosanct the legal consequences alone from inaccurate accounting would expose the project and its users to an extreme amount of liability.
So once again can we do the developing in development branch and make sure that production is always rock solid by not releasing stuff that hasn’t been fully tested to the production branch I am really frustrated with always having to patch and fix after bench update.
not knowing what ‘selenium testing’ is maybe an official beta-test procedure could help with this?
just from the top of my head: Core team announces an official beta test period (let’s say lasting a week or 2) here on the forum.
upon that users (ideally the ones who know what they are doing) test upgrading to clones of real production system’s and report issues back.
After that another 2 weeks are being used to fix identified problem before a new release (or maybe even a second test prior that round) is launched.
…
EDIT: I am sure it will be easy to find sufficient participants for such a procedure.
@rmehta: if you think that’s a good idea I can propose a standard procedure and gather testers in a separate topic (@imllc how about you?). I’d rather start such with your consent rather then just out of the blue
you should run at least a Trial Balance before and after any update which affects Accounts. The total Debit and Credit amounts M U S T match before and after any version bump. It doesn’t guarantee everything is ok but it’s a good start.
We have already discussed the Stock module has badly affected our accounts twice during migrations and to solve these issues took few weeks of investigation and we still have some visible scars in our Financial Statements. It is not easy to handle and justify in case of a legal auditing and it can become really costly. Please consider various stock and account settings. Our settings for instance allows negative stock and create an accounting entry for each stock movement.
status is that I wanted to come up with a procedure wise suggestion …
It’s just that I haven’t gotten to attend to this unfortunately. I’ll try to come up with something in the course of next week
You mean something like what we have pulled to solve our problem few months ago? Ref GL missing · Issue #5945 · frappe/erpnext · GitHub
In this case we warn the user when trying to post a Stock Entry after the Sales invoice.
My 2 cents worth. System maintenance 101
I agree with you are saying but sometimes it may not be feasible. How many customer environments are we talking about? How many customers have custom changes and the development team aren’t to know all that. Yes there has been some basic bench update errors but integrity of the systems should be up to each individual organisation. We also know the team building and maintaining ERPNext are very stretched.
If anyone just goes bench update on their production environment after seeing an update is making a very big mistake.
Always have 2 systems at your disposal (QA & PRD). make sure all changes in PRD matches exactly in QA and from time to time restore your PRD data to QA (this will ensure identical setup as well as test your backups).
Always run bench updates on QA first, test all your functions and once satisfied run updates in your production environment.