Tag Info

Hot answers tagged

7

One product, one source code, different data. There are not really enough details to know whether my answer is the right one, but your problem is a common one for solution providers with multiple customers who have slightly different requirements. The answers always some to converge on: Just One Product. When you build, you build everything and when you ...


5

The makefile for msbuild is the .sln file (or vcproj file). A typical msbuild command line would be something like: msbuild /p:Configuration=Release BigProject.sln The point of using msbuild is so you can script and automate the build process. Whether you were aware of it or not, TeamCity has been using msbuild all along.


4

In addition to the really good answer of FrustratedWithFormsDesigner I'd like to say what the non technical documents include (as we did it): the analysis data: what did the customer tell you when you first talked about requirements? the offer you made: the product requirement document and the functional specification document which together act as a ...


4

I would advise to think carefully about the different phases of release. For example, usually as a release is created it is built, tested, packaged and then deployed. Just because a solution builds together, doesn't mean it needs to be packaged together. And likewise, just because you have a single package, doesn't mean you need to deploy everything in ...


3

First point of fact is that the solution file pretty much magically becomes a MSBuild file when MSBuild executes it -- which is what happens when you build the solution in visual studio. In addition, all those project files are just msbuild files managed by visual studio. In fact, the project files handle most of the real dirty work here no matter if you are ...


3

QA as a whole is about assessing the risk that the product is suitable for the users to use. In reality, QA is not a 100% guarantee in part because it is usually impossible to test every possible action (including all non valid actions) in every possible environment. Since you have limited QA resource, you have to make decisions about where to focus that ...


3

Follow whichever documentation is applicable for your project from the following.You may already have some of them. Technical documentation: Details about PHP and information on how it is useful for the project Details about the back end and information on how it is useful for the project Information on Database connectivity along with suitable pictures ...


2

The best approach here is to have the Model of the MVC triad in a separate, common project. This Model should provide all the model features that are needed by the various versions. But the model should not implement the restrictions that differentiate the Simple version from the Advanced version. To take your example, if the Advanced version supports ...


2

Be Wary The potential documentation that you could give the client is virtually endless. Additional time required to generate documentation you don't already have is unpaid. Why does the client want this documentation (over and above the source code)? What will be done with it? Who is it for? The answers to these questions will help narrow the scope of ...


2

Hmm, trying to mandate how to factor a solution into projects is sort of like mandating how to factor a problem domain into objects in OOP. Good developers know how to do it. Bad developers don't. It is a bit of an art, and an acquired skill, yet is subjective enough that I would avoid mandating too much. I may have 6 different developers who are all bright ...


1

There are two approaches I can see: One may use user controls just like one uses objects to make primitive data types and basic types within the language or framework more explicit or to enclose logic within them. For example, in OOP, when you deal with percentage, one way is to use an int; a usually preferred way is to create Percentage class which will ...


1

I think having too many projects in a single solution is a bad thing. I have previously worked on the system that comprised of over 15 business domains. If I was to put them all into one solution, than I would end up with hundreds of projects. I suggest that you try and break these projects down into logical solutions (domains). In other words, work on ...


1

Re-using the issue tracker should be fine, as long as you're tagging the issues properly so that it's easy to differentiate between projects. Re-using the same repository is more convoluted. The advantage to this approach is removing potentially extravagant merges. On the other hand, it may become more difficult to deploy to test environments unless you can ...



Only top voted, non community-wiki answers of a minimum length are eligible