GIT and Scrum, the Two Most Important Things in Coding
Agile Scrum is the methodology that most tech teams around the world use. For every project, it has to be broken down wisely into subtasks, and picked up for implementation at the beginning of the cycle, "the iteration". Each person can take one or multiple subtasks of the project, or projects, to fill in the required number of hours in the iteration. And at the end of the scrum, every subtask, finished and unit-tested, are merged into one candidate branch for integration testing, regression testing, and eventually, for deployment on the production server.
This sounds like an ideal scenario.
We do the scrum planning meeting at the beginning of the sprint just to see what we can do in the sprint. One sprint could last 10 days, 8 hours per day, hence it's 80 hours per sprint. Minus some planning, meetings, code reviews, integration and regression testing of the previous sprint's candidate branch, and miscellaneous, we could probably have 50-60 hours per sprint for work. And we just fill in these 50-60 hours. No more. Hence, we do not need to work late at all, unless it's the scheduled release of something or critical errors pending fixed.
My Bad Experience
It could be very hard to achieve the ideal scenario, and many people give up. And sadly, despite my attempt to start all these, to try to implement, it was some points in time when everyone ignored. Hence, I saw many people staying late for work, trying desperately to finish the task, and do so many things at once trying to hit the other-worldly deadlines.
Because they wanted everything to be as dynamic as possible, they never concern any limitations or difficulties in the Tech Team. When we finish the coding, we push to the git, create the pull request, tell the team to review the code and approve the pull request, and then deploy immediately.
Imagine, you are working on another task, and your colleague asks you to review and approve the code immediately. Ideally, you have to commit your code, prepare your test data, checkout and pull the code for some small testing, and review the actual change of code. At the same time, you can also check for some more regression and integration testing. Anyway, due to the time constraint, we cannot do that so we read through the code, find the mistakes, ask for the change, read the code again, and approve. Obviously, integration and regression testing are impossible to be done.
And when it's the bug due to the lack of these two testings, we will have to fix it immediately.
That's why we should never do it this way.
Why Make It Project-by-Project Basis From the Beginning?
Because everything has to be dynamic. : Yes, we know that, but we could also schedule the release at the special timing.
Because when anything goes wrong, we could identify which project causes errors and revert. : Oh! But the lack of integration and regression testing means that we could be introducing the errors elsewhere without any errors caught during the unit testing for the project itself. Isn't this riskier? Yes, it's riskier. So, yes, go for the standard way of work if you can, so you can stay away from this kind of mistake.
Why points out which project while we'd rather prevent?
We know that every project could have bugs, so we have to put more effort into integration and regression testing before the scheduled deployment than just point out which project causes the error on production and revert. It made me feel like we are a kindergarten student trying to work hard to get things done so we just push things out, one by one, and - fingers-crossed - hope that nothing wrong happens.