Overview
No matter what kind of software you are producing there will be milestones. Unless you stick to some basic rules, this may a point in time, when everything falls apart.
Here is a simple list of do's and don'ts that can help you survive.
Do's
Prepare validation
If you have validation in place (outside the CI) run full suite before the actual validation starts.
I cannot stress enough how important this test run is. There are two major outcomes expected. First, you will know which tests are failing and may analyze whether this is due to a SW bug or a test issue. Keep in mind, that when the validation cycle starts there will be SW bugs coming, so it is unlikely to spend time on debugging tests. Secondly, test run can be a baseline, to which you may compare the execution results.
Code freeze
Set a date for a code freeze. The real code freeze. Meaning, no features are allowed to enter the repository after the CF - only critical bug fixes!
In few projects I have been working on, there were pseudo code freezes. People had been changing APIs, flows, etc. that other components had relied on, and in effect more bug fixing was introduced, delivery was slipping, everyone's frustration raised to alarming levels.
Defects prioritization
If you are not doing this already it is critical to set priorities to defects and set milestones criteria based on count of defects or even list of defects that needs to be fixed. After the validation cycle you should have a list of issues, decide which issues are critical to fix before the milestone, which are important to fix, but we can release with these, and which are negligible. Don't fool yourself that you can fix everything found during testing (if you have good tests in place), but for some of the issues there are workarounds (document those in release notes), some will hit small percentage of users and so on - these are the lowest priorities issues.
Licenses
License compliance should be really planned and checked in the early phase of a project, but as the development goes on programmers tend to find new useful components which they add to the code. If any of these components has restrictive license, to which you do not comply, you may find yourself in a serious trouble. It is usually better to delay the release, to clean up the code, than deal with legal issues later.
Release notes
By the first milestone you should establish release notes process (automatic if possible), to let know users about changes, limitations and known issues. Some of us tend to read this short summary of your work, and it can save you from answering the same questions over, and over again and more importantly can save user from wasting their time on trying a feature that does not yet fully work or is somehow limited. Work on the release notes seconds before publishing the release and you will surely forget to add something important to the document.
Plan team's holidays
This is often overlooked, but for the important milestones agree with the team who is critical for the release and ask them not to plan holidays during that time. If it is not possible, make sure every critical person has a replacement. Do I even need to explain what happens if an issue is found in a SW, 5 minutes before the release, and the owner of the component is on holidays and nobody knows how this SW works?
Don'ts
Last minute infrastructure changes
This is huge no-no. Never do that! Murphy's law will hit you hard if you introduce new infrastructure (new repo, new CI, new validation framework, you name it!), there is a high chance that something will break and everyone will be yelling at you.
Postponing performance testing till the end
If your software has performance requirements (and most software should have!) do not postpone performance testing till the last minute before the release. Performance issues may come from the invalid design and changing the design is usually much more expensive than changing few lines of code.
Last minute components
As one can devise from reading above text about the licenses, it is usually a bad idea to introduce new components right before the release. Aside from the legal issues, you may find issues with 3rd party code, which you do not know or you are incapable of fixing.
Summary
I try to stick to the above list in every project I am working on. It is sometimes a matter of presenting it to the other developers and finding a common agreement on such ground rules.
Do you have your own do's and don'ts?
References
[1] cover image
Top comments (0)