I am working on a SharePoint 2010 Server and i have following items in my SharePoint solution
Couple of web parts
State Machine Work flow (which will be integrated to an Infopath form library)
Infopath task edit forms
Lets say this solutions is deployed to http://[SharePoint201Server]:[PortNumber-x]/
This is the only server i have (No extra server for UAT), and what ever has been done so far needs to be given for user acceptance testing (UAT). I may create one more site at http://[SharePoint201Server]:[PortNumber-y]/ for it.
My problme is that how do i maintain two copies of my source code ? I will have to continue development on the same set of source code for next UAT release. I simply can not create simple copies of the source code as it will have same Assembly name and feature id, etc..As if i do so, any changes on under Development source code would affect UAT assemblies.
One thing i can do is to create seperate projects for UAT and Development with different Features and Assembly names, but is not that too much of an unneccesory work ?
What can be the best approach in such situation ?
i would suggest use sand boxed solution and create two site collection one for UAT and other for production. deploy your solutions individually on each sandbox solution. Sandbox solutions are deployed in bin not in GAC so you would not be having trouble code duplication
There is no best approach for this. You need to have different environments for development and UAT.
If the availability of machine is limitation, One possible solution is to have VM environment of the same machine for development and actual environment for UAT.
That obviously requires sophisticated hardware configuration to run both simultaneously.
Related
Good Afternoon,
I'm a little new to the Release Management Department and I've been tasked with converting our Release Management 2013 templates over to 2017. I've ran into a road block recently that I've been unable to figure out how to proceed, and wanted to consult the experts for tips or suggestions.
The most major issue is that Release Management 2017 doesn't offer the ability to setup Environment Tags, meaning I can't setup a "Production" environment and tag all of our production IIS servers in it in order to run a single command against all the servers. This hinders me greatly.
I've done research on this issue and have come to two possible work arounds. Either 1) Creating a release template for each IIS Site or 2) Creating a Release Template for each Environment (Test/Stage/Prod). The problem here is that we managed over 100 different IIS Sites and Databases, so creating an individual template for each site would be...astronomical. Whereas creating one bulk template for each environment could lead to issues down the line if we needed to release a specific site.
I figure that we are not the only company that work with this many IIS Sites, and that someone has to have figured out a better solution that the two above. Do we need to look elsewhere other than TFS2017 (With built in RM Features)?
I appreciate any and all advice on the issue.
The tasks you'd be using to target your servers (such as "PowerShell on Target Machines") take a list of servers to execute against. You can store the server names in a variable on the release definition at the environment level.
In TFS 2017 Update 1, you'll be able to store related variables in variable groups and share them across release definitions.
I've a VM (#1) with installed SP 2010 and SQL Server 2008. It suites our needs in terms of load and capacity. In case of breaking down we can revert it to the snapshot.
The development process still goes on.
The question is what is good approach for updating the production VM?
Variant 1:
Have a copy of production VM (#2)
When the iteration is finished (development->testing->fixing) and we ready to make update we swap the VMs (#1 <--> #2)
Testing VM #2 becomes production and #1 becomes testing one.
" + " : We go live with fully tested solution.
" - " : Mechanism for sync up between VMs is required.
Variant 2:
Develop, test and fix on the production VM
Publish changes when we are ready.
" + " : We don't need mechanism for sync up between VMs
" - " : Crashes can happen more often.
Any suggestion will be appreciated.
TIA
Do NOT do your development on the production VM. SharePoint is very easy to break during development and you will more than likely bring down your production environment at some point. The risk is basically too high.
Do your development on a separate system. Package your solution/changes properly as a WSP - test it on another system (in between your dev environment, and basically a copy of production). Once it passes all testing on your staging server, deploy the WSP to production.
Swapping systems is a pain in the arse when it comes to SharePoint - you have Alternate Access Mappings, IIS Bindings etc. to worry about - and takes more time and effort than simply just uploading a new WSP and hitting "deploy" (obviously, after testing on your stating server).
It really depends on "what" you are developing:
Content only
It is often easier to do this on the production machine. The standard publishing framework should be sufficent to hide changes from standard users.
Or you could use the content deployment features of sharepoint to move it from the dev farm to the production farm
Or you could use the content deployment tool
Webparts, simple components
In 2010, these should be done as sandboxed solutions (if you can get away with it), then they are very simple to upload/change on your prod environment. Build on your dev enironment, then upload through the sharepoint webpages.
Complex components
Things that require a farm administrator to install on the server (jobs, complex web parts, etc), should be developed with visual studio on your dev box, then moved to prod in a fully tested way. Try having a testing/stage environment.
A combination of all of the above
This usually depends on how much risk your client is willing to expose themselves to, say for instance, if it is a brand new server there is not much risk in taking down users of the system.
I would not recommend installing visual studio on a PRODUCTION SharePoint server
Why does Microsoft suggest using WSPs for production deployment in SharePoint? What are the other methods for production deployment?
WSPs are suggested as they are deployable 'bundles' of functionality, whether that is an Event Handler, Application page or Web Part. By using WSPs you can create and test them in Dev and then roll them out to production once they have been tested. A WSP can be easily managed from the Solution store in Central Administration
It is possible to deploy features by putting the necessary files into the 12 Hive (SharePoint ambiguously named folder), but this requires manual changes to the system. If you have several Web Front Ends (WFEs) in a web farm, then you would need to manually maintain each of them. When using WSPs for deployment, the updates can be deployed to all Servers from one location.
WSP files are designed for deploying functionality to SharePoint in a consistent manner. Although technically they don't do anything you can't do by just copying files to the server, relying on manual deployment is a great way to put the system into an inconsistent state. It may work at first, and even be quicker/easier in some cases, but sooner or later you will permanently break your production environment.
The wsp was specifically designed for the purpose of packaging and deploying SharePoint 2007 solutions. That's why Microsft suggests using it!
While there are a few limitations to it, it's by far the best way to deploy solutions into a prod environment.
You should use WSPs to deploy in SharePoint.
I have used this WSP builder and it's makes your life a little easier.
http://www.codeplex.com/wspbuilder
I feel like I need a better defined framework for updating my SharePoint (MOSS 2007) application with custom code changes. I am creating wsp solution files with features and new types and such, but once those get tested and deployed, I feel like it's a bit of a leap of faith, and that makes me nervous and occasionally reluctant to deploy changes. After deployment, it's difficult to correlate the current state of the SharePoint application with the specific code that is deployed on that SharePoint server. What features are actually installed and on which sites? Which features are activated or deactivated? Which version of this custom field or content type is really there? Things like this. If an error crops up, I have to rely on my assumptions about what code is there and actually running, or I have to spend time digging through deployed assemblies and the 12 hive -- not impossible, but pretty unpleasant.
What steps should I take to improve my ability to unambiguously determine the state of the application and find the code that truly represents that state? Are there third-party tools that can help with this?
I feel your pain... Application Developyment Lifecycle with SharePoint 2007 leaves me with a bitter taste in my mouth.
To answer your question. We built our own deployment utility that does a few things for us.
Checks state of key Timer Jobs (too many times we would do a deployment to find one WFE that did not get deployment)
Checks state of key Services on all our web front ends (again we want to know health of farm before we start kicking off timer jobs).
Shows file version and date of selected assemblies from GAC (does this across all Web Front Ends). We have seen problems before where assemblies did not get installed correctly across the farms.
Updates web.config settings based on an custom XML scheme we provide. We ran into some problems with web.config updates so we have thought about creating a utility to validate the web.config (specifically make sure there are no duplicate entries for specific keys).
Push content type updates (first time content types are deployed via feature it works great, but as soon as you need to update that content type it gets tough).
Checks status of WSP package after deployment or upgrade.
This utility uses the SharePoint API to do most of this work. Some of it is done by checking WMI Events.
Unfortunately the SharePoint development experience is lacking in this regard. As long as you are "namespacing" all features deployed using solution packages, you can use solution management from central admin to keep track of versions, and what gets deployed to which site collection.
Features are scoped from all levels from the farm to an individual web; so maintenence from that level is a little tough. I just try to organize all deployed code from the (top down) solution level.
It gets even more complicated when deploying custom timer jobs, event handlers, etc; I really hope that version next will address a lot of these common developer concerns.
Isn't the only way that you have a planned/controlled deployment process and a version management system like TFS
In the current project I am involved in we have:
Continuous builds
Daily Builds on a development server
When we release something to test we merge the code to the Main bransch in the version management system (TFS)
When tested and ready for production then we merge the main bransch to the release bransch
Using this structured way we always knows what is deployed in what environment and can also track all changes based on environment or changes in requirements(are also tracked in TFS)
We are starting with Sharepoint development with a team of three and are currently setting up our development environments. We would like to avoid installing a Server 2008 for each developer, thus a single terminal server has been setup, using Remote Windows to start a VS2008 instance on each developer's machine. Now we would like to separate developers' testing environments (i.e. a different site colletion per developer), but have realized that the assemblies would need to be installed into GAC to show properly on the site. But since there is AFAIK only one GAC, developers wouldn't be able to test their stuff independently.
Is there any way we could create separate testing environments without installing a bunch of 2008 Servers?
So you're all going to remote in an fire up Visual Studio and be compiling stuff and restarting IIS, etc?
You're going to be stamping on each other's toes.
A wiser choice nowadays is to use Hyper-V (or some other virtualisation).
We use Windows Server 2008 on our laptops, and use Hyper-V to run our dev environments. We then have a dev environment (sandbox) each, and these have VS2008, SVN, Nunit, etc.
Our code is tested against each other thanks to CruiseControl on the only shared Hyper-V.
This has been great for us... we distribute the load, we can work on the move, we don't step on each others toes and if we need to do a demo we can switch Hyper-Vs and demo from the demo Hyper-V (branched from the dev one early on so that the environments are known).
Go virtual and don't look back.
PS: I've just seen your comment about one server... just put Hyper-V on that and run 3 instances. That's also what we do ;)
I don't know about installing the server on everything, but this sounds like an ideal task for Virtual Machines rather than physical ones- where I work we using VMWare a whole lot for this kind of work and it does very well.
It's also useful to be able to roll back to a snapshot when it comes to testing installation processes and so on.
No. In addition to the GAC there are all the SharePoint files in the 12 hive, such as features and site templates. It's not worth what you save on server costs.
(Of course if you don't use the GAC, but deploy to the bin folder, and you don't touch anything in the 12 hive, you can give each developer their own web application on the same server. But this approach puts a lot of restrictions on what they can do. It's still not worth it.)
Virtual machines will work, but they can be slow to develop on. For instance, you'll need to restart the application pool for every GAC deploy - which means a pause of maybe 15-60 seconds to reload the application, (depending on the hardware). This will become annoying.
Virtual machines work better for test and production, where you don't restart the application so often.
I recommend a physical server for each developer. This will minimize the code-deploy-test cycle time, and make sure they don't have to worry about stepping on each others toes.
You are on the wrong track with Terminal Services - its just not going to give you any separation.
A lot of people do recommend developing on W003/2008 server directly, and it does simplify some things like remote debugging.
I prefer the more traditional method of using VMWare to run virtual machines. These can be running on a local or remote host. Remote debugging is a little more complex to setup but still possible.
Finally - if possible then deploy to the bin dir rather than the GAC. This will make it much easier to deploy automatically after compilation.
The contributors are right that there are lots of stumbling blocks to multi-developer single server environments.
Number one developers will be trying to attach to the same Web Application process w2ps.exe so creating separate Web Applications on different ports is a must unless you are prepared to share time debugging. How to setup a development environment for sharepoint 2013
The second problem is when you try to collaborate and use shared components/features. Having a desire to work separately is debatable, I believe that the team developers should be collaborating and sharing so combing work is desirable to ensure seamless integration into a single final solution and that no work is duplicated. The multi-developer single server environment works perfectly 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 totally unrelated components and never need to do common things such as restart IIS or attach a debugger to an IIS process, this type of environment generally doesn’t work well.' http://technet.microsoft.com/en-us/magazine/dn145990.aspx We made this mistake through lack of experience and knowledge, but once you make it it's possible to work round it.
My first attempt to share features was to copy developer 1's project into developer 2's solution and add a reference to it in developer’s 2's project and add all the features to developer 2's package. Deploying this works fine for developer 2, until as I discovered if developer 1 detaches their solution from the debugger it retracts the solution based on the duplicated solution id from the farm and therefore from each developer's web application. Therefore developer 2 has the rug pulled out from underneath them. Although this is a part solution and seemed to work for a while, it took me a while to work out what was happening and what combinations of dev 1 and 2 deployments make each other’s work and not work.
So I found a better solution. Under the project properties in Visual Studio under SharePoint tab there is a combo box called 'Auto-retract after debugging'. This by default retracts the solution when the developer stops the attached debugger and pulls the features out from underneath the other developers. Unticking this box prevents the retract and leaves each developers individual solutions deployed at farm level and on reattaching to the debugger just replaces the solution with minimal fuss.
In my experience recycling the IIS application pool is so fast other developers don't even notice, but with a larger team than 2 this might become more prevalent, so perhaps someone else could add their experiences. I also guess unless the other develops try to attach at exactly the same time that the recycle is happening it'll be fine, so is a really small chance of having a cross over time, and simply detaching and reattaching will fix this if it is ever experienced.