Frequent Product Setups Adversely Affect The Release, Don’t They?
The project should be configured & set up every day. Sometimes they say that some projects are so huge that their configuration cannot be edited once a day. Does this mean that they include more than 40 million lines of code forming the basis of Windows XP or Windows Server 2003? Given that these operating systems are the most ambitious commercial software projects in history and yet are configured every day, we should not think so. So, the non-daily setup of the program cannot be justified. You not only need to configure the project every day, but also automate this process.
During the setup process, it is necessary to simultaneously configure both final and checkout layouts. In fact, the debug builds are very important. Unsuccessful build of the program is a big sin. If developers have registered a code that is not compiled, the perpetrator must be punished. Public whipping would probably be a somewhat harsh form of punishment (though not too much), but there is another method: make the guilty publicly repent “the crime” and buy donuts for the entire team. At least in certain groups, it always gave excellent results. If your team does not have a staff member responsible for the setup of the program, you can punish the person who caused the software build to fail, assigning him responsibility for the configuration until this duty is imposed on his fellow in misery. To avoid all these problems, it is reasonable to use services of QA company across the development life cycle.
One of the best practices of daily project setup that competent persons have ever used is to notify the members of the team by e-mail at the end of the process. With the automated nightly configuration of the product, each member of the team can immediately know in the morning whether the setup has succeeded; if not, the team members can take immediate action to remedy the situation.
To avoid problems with the configuration of the program, each member of the team must have the same version of all the tools and components relative to the setup process. As it was already mentioned, in some groups this is guaranteed by storing program build system in the version control system. If team members work with different versions of tools, including different versions of service packs, they create the ideal basis for errors when building a program. If there are no convincing reasons for using someone else’s version of the compiler, no developer should update their tools sua sponte.