Testing Deployment for Sharepoint by Multiple Developers on the Same Server
We are starting off with Sharepoint development with a team of three and are currently building a development environment. We wanted to avoid installing Server 2008 for each developer, so we configured one Terminal Server using Remote Windows to run an instance of VS2008 on each developer machine. Now we would like to separate the developer testing environments (i.e. a different site on each developer), but realized that assemblies must be installed in the GAC to display correctly on the site. But since AFAIK there is only one GAC, developers won't be able to test their stuff on their own.
Can I create separate test environments without installing the 2008 Server Group?
source to share
So you're all going to remotely start Visual Studio and collect stuff and restart IIS, etc.
You're going to throw your toes at each other.
Currently, the smarter option is to use Hyper-V (or some other virtualization).
We are using Windows Server 2008 on our laptops and using Hyper-V to run the development environment. Then we have a developer environment (sandbox) and they have VS2008, SVN, Nunit, etc.
Our code is checked against each other thanks to CruiseControl on the only shared Hyper-V.
It was great for us ... we distribute the load, we can work on the move, we don't step on each other, and if we need to do a demo, we can switch Hyper-Vs and demo from the Hyper-V demo (forked from dev to early so that the environment is known).
Go to virtual mode and don't look back.
PS: I just looked at your comment about one server ... just put Hyper-V on it and run 3 instances. This and what we do;)
I don't know about installing a server on everything, but it seems like an ideal task for virtual machines, not physical ones - where I work, we use VMWare for this work, and it is very good.
It's also helpful to be able to roll back to a snapshot when it comes to testing installation processes, etc.
source to share
Not. In addition to the GAC, there are all the SharePoint files in 12 hives, such as features and site templates. It's not worth saving on server cost.
(Of course, if you don't use the GAC, but deploy to a bin folder and you don't touch anything in the 12 hives, you can provide each developer with their own web application on the same server.The approach imposes many restrictions on what they can do. It's still not worth it.)
Virtual machines will work, but they can grow slowly. For example, you need to restart the application pool for each GAC deployment, which means a 15-60 second pause for the application to reload (depending on hardware). This will get annoying.
Virtual machines perform better for testing and production, where you don't restart the application as often.
I recommend a physical server for every developer. This will keep your code testing cycle time to a minimum and make sure they don't have to worry about stepping on each other.
source to share
You are wrong with Terminal Services - it just won't give you any separation.
Many people recommend to develop on W003 / 2008 server directly, and this simplifies some things like remote debugging.
I prefer the more traditional method of using VMWare to run virtual machines. They can run on local or remote host. Remote debugging is a bit tricky to set up, but still possible.
Finally - if possible, then expand it to the bin directory, not the GAC. This will make it easier to deploy automatically after compilation.
source to share
The authors agree that there are many stumbling blocks for single-server, multi-developer environments.
Number one developers will try to hook into the same w2ps.exe web application process, so creating separate web applications on different ports is a must unless you're willing to share temporary debugging. How to set up a development environment for sharepoint 2013
The second problem is trying to work together and share common components / features. The desire to work separately is debatable, I believe that the developers of the team should cooperate and share with each other, so combing the work is desirable in order to ensure seamless integration into a single final solution and there is no need to duplicate work. A multi-user single server environment works fine until you try to collaborate "One common mistake is to have one" development server "used by all team developers. Unless team members are working on completely unrelated components and should never do common things like restarting IIS or attaching a debugger to an IIS process, this type of environment usually doesn't work. " http://technet.microsoft.com / en-us / magazine / dn145990.aspxWe made this mistake due to lack of experience and knowledge, but as soon as you make it so that you can work around it.
My first attempt at sharing features was to copy the developer 1 project into the 2 developer solution and add a reference to it in the 2 developer project and add all the features to the 2 developer package. Deploying this works great for developer 2 until I found that if developer 1 detaches his solution from the debugger, he pulls the solution based on the duplicate solution ID from the farm and therefore from each developer's web application. So Developer 2 has a rug pulled out from under them. While this is part of the solution and seems to have worked for a while, it took me a while to figure out what was going on and what combinations of dev 1 and 2 deployments were making each other work and not working.
So I found the best solution. In the project properties in Visual Studio, under the SharePoint tab, there is an Auto Rollback After Debug combo box. This defaults to overriding the decision when the developer stops the attached debugger and pulls features out from under other developers. Enabling this block prevents disconnection and leaves every single developer solution deployed at the farm level, and when reconnected to the debugger simply replaces the solution with minimal noise.
In my experience, recycling the IIS application pool is so fast that other developers don't even notice, but with a larger team than 2, this can become more common, so maybe someone can add their expertise. I also assume that unless another developer tries to connect at exactly the same time as the recirculation is occurring, everything will be fine, so this is really a small chance of having a cross over time, and simply disconnecting and reconnecting will fix that if it does ever experienced.
source to share