I am using Team Foundation Server by Microsoft. I will probably migrate from one account(server) to another account, and I would like to preserve following things:
source control of files
users
scrum sprints (epics, backlogs, tasks, bugs)
builds
Azure subscription:
move all web services
move all sql databases
How can I approach this? Is this manual work one by one, or can I use some tool for migration?
There is a TFS migration tool / body of knowledge that will help you thought most of the items you list under TFS. You can find it here. This should be fairly straight forward unless you have customised process templates which then create a few more headaches. Moving Builds may be tricky, there is a recently released article on scripting builds with YAML which may be of use.
For the Azure components, you can:
Move databases between subscriptions
and I believe you can do similar for WebApps/Services. You can also move subscriptions using PowerShell.
Related
I am working with a customer which have SharePoint 2013 dev, test and prod environments sitting in a datacentre. We are moving the datacentre which means their SharePoint 2013 needs to be moved as is. They have 1 heavly custom build application on top of SharePoint which needs to be moved. I need confirmation, process suggestion on the migration part.
I install SharePoint 2013 like for like in new environment.
Option 1
I take backup for their databases and restore them on new SQL Server. Use Mount-SPContentDatabase to mount database and test if everything is working as expected
Option 2
Recreate web application, site collections, activate custom features, timer job and migrate content.
I personally think that option 1 is more applicable but need input and suggestions. Any road blockers or gotcha are also encouraged.
Thanks for sharing your experience
As its a same version migration it wont be much of an issue but go with option 1.
Re Creating the whole farm is so hard specially if you decide to deploy each and every component.
I've migrations to same version and these are the steps that i follow.
Create a checklist of all solutions and features (WSP etc).
The check list should have the same services that are running in the farm as well.
Install SharePoint in the new farm and update to the same version as the existing farm , having same version will reduce a lot of
problems.
Create the service applications just like the existing farm.
Restore the service application databases (MetaData, UserProfile etc)
Create the web application and restore the content database
Deploy the custom solutions
Confirm that everything in your checklist is deployed and working fine
Fix errors if there are any
This is the flow that i follow and so far i've been successful.
Good Luck
Previously when provisioning list, libraries, site columns, content types, list definitions etc in SharePoint I typically used SharePoint features, deployed via a WSP - or used PowerShell scripts. This meant I had a package that could be deployed to DEV / TEST / PROD.
I'm working with SharePoint within Office 365 and unsure on the best way to provision lists / libraries / features within SharePoint.
Options:
No Code Sandboxed Solutions
Trying to avoid using these as the information from Microsoft on whether they are deprecated is flaky - however sandboxed solutions would allow me to deploy features with list definitions etc. I know sandboxed solutions with c# are definitely deprecated, but the info around no code solutions is poor.
Apps
I know apps can provision at both the app and host web level, but creating lists, libraries etc using the CSOM seems like a lot of effort and a step backwards.
PowerShell
The SP Online PowerShell is nowhere near as powerful as on-prem SP. I can provision site collections through this, but not lists or libraries...
I'm keen to know how other developers are deploying to Office 365, specifically around provisioning sites with specific list definitions, libraries, content types and so on...
Thanks
Microsoft did clarify the position on No Code Sandbox solutions - http://blogs.msdn.com/b/sharepointdev/archive/2014/01/14/deprecation-of-custom-code-in-sandboxed-solutions.aspx
Also if you are looking at using Powershell to deploy then you might want to go down the route of using CSOM from within PowerShell - SharePoint Client Browser for SharePoint 2013 is good for setting up a session also very good for viewing the content of a 365 tenant - http://spcb.codeplex.com/
I have been using code based provision for almost two years without any issues at all.
Server side model works just fine, CSOM has some limitation but stil cool one and JSOM could deliver the same feature set as both CSOM and SSOM, sorta 95% :)
PowerShell is not the best option as it hard to integrate into CI, put some unit testing and regressions.
As you mentioned, this is "step back", but if only you don't have any framework or foundation for that. My libraries are internal one, but there is SPGenesis at codeplex and SPMeta2.
As community don't really care, need or with such libraries for provisioning (yep, let's face it), there are much such libraries at all, but there are lots of "MVP" samples sorta "hello world" level.
Finally, what I would suggest is to invest your time and effort in code based provision.
This is a future, that's it ;)
UPD
Struggling with SharePoint's API inconsistency, bugs, "by-design" behaviour, unaffordable amount of time to write, support and upgrade WSP packages and XML, a team of passionate SharePoint professionals decided to come up with robust, testable and repeatable way to deploy such artifacts like fields, content types, libraries, pages and many more.
Enjoy and let us know how it goes.
SPMeta2 at GitHub
SPMeta2 at Nuget
SPMeta2 Documentation Wiki
SPMeta2 Bugtracker
We are working on a web application (Javascript + php). We want to start using Team Foundation Server in order to apply application lifecycle management. but we don't know where to start! any good guide or tutorials?
If you are investigating TFS to be used as an ALM tool in your company, you probably want to take a look at the free preview of the service that is available in the cloud. That will allow you to see if this tool will get you what you need. There a lots of tools out there, but first you need to figure out what your problem is and what you are trying to solve. TFS may not be the solution you need, but it is a solution for certain teams.
You'll probably likely be using TFS as an ALM tool for the following:
Source Control. Ensure you have version history on your changes. Note: You can now tap into GIT as your repository, if you don't want to use the TFS source control.
Continuous Integration. You can make your build configurations deploy your files out to your environments, and run unit tests if necessary.
Bug Tracking. Use the built-in work items to track all your bugs.
Requirements Tracking. Use Scrum or Kanban for your project to take advantage of the boards that are available with the service. Work items like 'Stories' or 'Product Backlog Items' will let you track the work your team is delivering.
Burndown. The built-in reports should help you report to your management on progress, though you'll have to see if the TFS ones meet your needs.
Test Cases. Your QA team can write their test cases in TFS to document how to test the requirements. If you have the correct license, you can also tap in Microsoft Test Manager for your QA team to execute and plan their tests.
I would strongly advise doing some research into what ALM means, what it is used for, and why you should be doing it before deciding on a tool. The tool won't fix the problem, it just supports you in whatever you are doing to fix your problem.
We are deploying sharepoint MOSS 2007 at our work. I'm trying to come up with a sharepoint development and deployment methodology. We have Dev/QA/Prod environments and I need a way, preferably automated to deploy changes from Dev to QA and from there to prod.
We are creating site collections web parts etc. Some of it is done directly within sharepoint, some through Sharepoint designer or visual studio. I'm looking for a way to extract this and deploy it to other enviornments.
I tried stsadm backup/restore import/export etc but they all move the data along with it as well. I just need the structure deployed. Content deployment paths and jobs does the same thing as well.
We use MSBuild & Curisecontrol.net for other .net projects to automate build/deployment process. I'm looking for something similar with sharepoint if possible.
What are your best practices for this? Since my team is learning we don't have a defined process and we are open to change our development process if needed.
First off, it's a hard problem.
Probably the 'best' method is to put everything into solution packages - but its quite hard to do correctly.
There is a lot of opinions out there - the best I can do is give you further reading
SharePoint Solution Deployment Strategies
SO - How do you deploy your SharePoint solutions?
ROSS - A commercial toolset to help with deployment
DocAve Deployment Manager
SharePoint development / deployment isn't as finely tuned as it is with regular .NET. I haven't heard of anyone using CI solutions for this.
Your basic unit of deployment is a solution package (a WSP file). It's basically a CAB file with a different extension. WSPBuilder is helpful for creating them. (http://wspbuilder.codeplex.com)
SPSource (http://spsource.codeplex.com) is pretty good for reverse engineering some stuff that you build in a web browser, such as Content Types and Lists. It's my preferred way of doing this stuff - trying to cut them by hand is no fun. I've had SPSource reverse engineer simple lists into 2000 line XML files.
Powershell is important for SPT 2010. James Kovacs has built a build tool called psake which plugs into PSH. It looks pretty straightforward, though I need to figure out PSH properly first.
Spend some time on http://sharepointdevwiki.com as this an evolving resource.
Microsoft patterns and practices group have released some guidance as well at http://msdn.microsoft.com/en-us/library/dd203468.aspx
LearnDevNow.com is also selling online training videos that are pretty good and very affordable (about USD100). They will show you many of the good ways of doing things.
Cheers
Mike
Does anyone have any strategies/tips/traps for moving to Team System? Should it be done in baby steps, or all at once? Should we migrate our SourceSafe library over, or draw a line in the sand and move forward? Is it worth brining SharePoint into the mix? Any thoughts are appreciated.
I've never had to migrate to TFS, but have used it pretty extensively for the past couple of years.
Regarding your question on Sharepoint, we've found it pretty useful in conjunction with TFS. We use it primarily for documentation management and for storing other "non-technical" artifacts related to the project. Some dev teams advocate keeping documentation in source control alongside source code, which is OK, but in my experience our project stakeholders have an easier time accessing relevent project documentation via the Sharepoint portal than they would having to interface with source control.
I basically was able to distribute the URL to the sharepoint site associated with our TFS team project to the concerned non-technical team members and have been able to avoid constantly e-mailing documents around, so it's been great for us.
It may just be too much work to do it all at once.
I feel that it is easier to divvy out projects to different people one at a time.
That way they can move them across and ensure that each works okay before closing out the SourceSafe.
You will always want a backup of the SourceSafe "database" around just in case.
I do not know how to migrate from SourceSafe to TFS and keep the comments and versions.
By far the easiest it to just add the projects in, but having migrated that way in the past, we always missed the ability to find out what others had done to particular files.
If you find a way to migrate, I would go that way unless it is hideously expensive.