When creating a new build definition, we have the Process section as below snapshot where the items in the list is untouchable - i.e. I don't know how to refresh and/or clear that list and add new ones (by hitting New button next to it).
If you know how to, please share.
ps.
A google for this question comes up with this discussion; and it seems the cache folder might relate to this issue.
Similar solution here can be applied to this question.
Use the below script to delete the registed build process template in TFS database:
use Tfs_YourTeamCollectionName;
delete from tbl_BuildProcessTemplate where ProcessTemplateID = 'Your ProcessTemplateID';
Create/Edit new build definition again.
The database name is your TFS team collection name e.g. Tfs_YourTeamCollection in the backend SQL Server of your TFS server.
I'm using TFS 2012.
Hope it helps!
Related
Following Azure DevOps documentation, I have deleted a number of projects. The project is removed from the online view but strange folders now appear in VS 2017 source control explorer. These folders contain source code from the deleted projects.
I tried to delete and resync my workspace but the unwanted folders synced again. Can anyone who has seen this behavior advise how i can get rid of them?
br Nico
Edit:
It seems like this is not a new issue. I am able to reproduce this with TFVC projects only. Take a look at this post about how to remove "deleted" team projects. Hopefully that gets you moving in the right direction.
If all else fails... use Git :)
Original:
It seems to me like VS is holding onto some information about the remote and which projects it expects to be there.
You may simply need to refresh the connection in VS.
If the refresh still shows the deleted projects, try removing the server connection completely, and adding it fresh.
I'm migrating a sharepoint site from the root site collection to another site collection in the way that my old url is http://domain.com/sitename and the new site is in http://domain.com/sites/sitename. I'm using the Export-SPWeb and Import-SPWeb command line tools to execute this operation. The operation is successfully executed, all the library, lists, etc are exported just fine. Except the site's Tasks list. =( The old completed tasks are not important for me, but the newly assigned tasks are. So the way is to get all of them just as the original site. The list associated to the workflow that generetes the tasks is exported just fine also. But not the tasks. I appreciate your help. Hugs.
Try to create Task list template and move this template to another site manually.
http://office.microsoft.com/en-in/sharepoint-server-help/copy-or-move-a-list-by-using-a-list-template-HA101782479.aspx#_Create_a_list
I am working on a SP2013 project for a customer, and I need to set up a working environment for development, testing and production. Let's assume for the sake of simplicity that the work consists only of various customizations (lists, libraries, apps, themes etc.) and no code.
My setup is as follows:
The production environment is on some servers on the customer site
The test environment is set up in Azure
The development environment is on a virtual machine on my PC
Now, let's assume everything is set up correctly on each environment, and I want to be able to support the following tasks:
I do customizations on my dev environment, and want to deploy this in test for others to test, prefereably with existing data
After testing and QA, I want to deploy from test to production. This must of course only affect customizations, not existing data
Every now and then I would like to take a snapshot of the production environment and move it to test, so that the deployment of a new feature from development can be done as realistic as possible
I want to perform these tasks as smoothly and efficiently as possible, especially when deploying from dev to test which is done often. Deploying from test to production will not be done that often, and hence some more manual work will be tolerated.
I know of a few mechanisms that might be relevant:
Content deployment
Cross site publishing
Content database backup/restore
Save site as template, export wsp and import
(Last resort) Manually set up each customization by hand
Could some of you experienced SharePoint devs/admins make some recommendations as to which mechanism to use in which situation, when to not use it etc.? Are there other methods that should be mentioned? Remember that the three environments reside in separated physical environments, which will probably make a fully automated solution difficult. Would it make it easier if I set up the test environment on the customer site (i.e. part of the same farm)?
Another option depending on your specific customisations might be a third party tool. There are a number of them out there. ShareGate is one I have personally been using for migration work and seems very simple and effective for moving content around quickly between environments. Attunity Repliweb for SharePoint is another that might be worth looking at for the sort of development specific release work that you require.
As for native options, I am still finding my way as well but here are my suggestions :
Where possible I have used Visual Studio to create solution packages containing features to deploy pieces of functionality. A branding solution package for example might include several features that deploy your custom master pages, theme / look files, common JavaScript libraries and images.
Feature deployment makes it easy for you to deploy or remove functionality between environments and to reuse functionality between sites. Additionally you can add your Visual Studio solutions to a source control system such as VS Online or GitHub.
For one off sites I have created a dev site, configured it then used the built in SharePoint backup and restore to deploy it to prod. Subsequent changes have been created in dev and then manually applied to test and prod. Depending on the customisations this has been quite time consuming. You might combine this with a tool such as ShareGate to automate the deployment of individual artifacts such as a customized list from one environment to another.
For moving content around I have been using a combination of ShareGate for things such as documents alongside Boost Solutions Excel Import for handling list data. This allows me to export large amounts of list data to excel and easily reimport it into a new list which might be a copy that I have added new functionality to in preparation for replacing the old prod list or perhaps dev / test lists that I am populating before doing a full site backup to restore to production.
Good luck and hopefully some of these suggestions are useful to you ! I will be following this question as I am also interested to hear of better methods / habits for managing the SharePoint development cycle.
I finished setting up a development environment for a SharePoint 2013 production environment that I maintain. The last step was to move my production content to my development environment. I had to dig around a bit to find the PowerShell etc. Rather than go through that again next time, I decided to write a blog about it, so that I’d have all the steps in one place.
The first step is to back up the content database that you want to restore to development. To do this open up SQL Server Management Studio, right-click on the database you want to back up, hover over tasks, and select backup. You will be presented with the Back Up Database window. Make sure that your backup type is set to full, give the backup a name or stick with the default, and note or change the destination.
You can skip these steps if you have scheduled backups running and are able to access the backup drive. In that case just go grab a copy of the most recent full backup and copy it to your development SQL Server.
The next step is to restore the database to development. To do this open up SQL Server Management Studio in your development environment, right-click on the Databases folder, and select Restore Database. When presented with the Restore Database window, click on the Device Radio Button and click the ellipsis next to the text box. This will bring up the Select backup devices window. From there click Add, locate your backup file and click OK, click OK again to be returned to the Restore Database Window, and finally from there click OK. Now your database has been restored, and you are ready to add it to SharePoint.
If you don’t already have one with content in it that you don’t care about in it, create a new Web Application…
https://sharepointv15.wordpress.com/2012/07/24/create-a-web-application-in-sharepoint-2013/
Don’t worry about creating a site collection.
Now go to Central Admin and click on Manage content databases under Application Management.
rsd1
Make sure that the correct Web Application is selected. If it is not click on the drop down arrow next to the Web Application name, click change web application and select the correct Web Application in the window that you are presented with.
rsd2
Next click on the Content Database name
On the Manage Content Database Settings screen scroll down, click on the Remove Content Database check box, click OK on the warning pop up and click OK at the bottom of the screen.
rsd3
Now you’ll need to open up the SharePoint 2013 Management Shell as an administrator. To do this click on your start menu, click all programs, click on the Sharepoint 2013 folder, right-click the SharePoint 2013 Management Shell and select Run as Administrator.
From here you will run the Mount-SPContentDatabase cmdlet
Mount-SPContentDatabase “MyDatabase” -DatabaseServer “MyServer” -WebApplication http://sitename
Click below for details on this cmdlt…
http://technet.microsoft.com/en-us/library/ff607581.aspx
At this point you should be able to navigate to the web application URL and see the Site Collection that lives in the database you just mounted.
Note: This will work in SharePoint 2010 or SharePoint 2013. However, the database must be the same version of SharePoint that the farm you are trying to mount to is. If it is a lower version it will automatically try to upgrade it, so keep that in mind.
follow the below link.
https://sharepointv15.wordpress.com/2013/03/21/moving-content-between-environments/
I am trying to backup a whole Sitecore website.
I know that the package designer can do part of the job, but not entirely.
Having a backup is always a good way when the site is broken accidently.
Is there a way or a tool to backup the whole Sitecore website?
I am new to the Sitecore, so any advise is welcome.
Thank you!
We've got a SQL job running to back-up the databases nightly.
Apart from that, when I deploy code and it's a small bit I usually end up backing up only the parts I'm going to replace. If it's a big code deploy I just back up the whole website (code-wise anyway) before deploying the code package.
Apart from that we also run scheduled backups of the code (although I don't know the intervals), and of course we've got source control if everything else fails.
If you've got an automated deployment tool you could also automate the above of course.
Before a major deploy of content or code, I typically backup the master database and zip everything in the website directory minus the App_Data and temp directories. That way if the deploy goes wrong, I can restore the code and database fairly quickly and be back to the previous state.
I have no knowledge of a tool that can do this for you, but there are a few ways you can handle this in an easy way:
1) you can create a database backup of the master database, but this only contains content and no files like media files that are saved on disk or your complete and build solution. It is always a good idea to schedule your database backup every night and save the backups for at least a week or more.
2) When you use the package designer, you can create dynamic pacakges that can contain all your content, media files and solution files on disk. This is an easy way to deploy the site onto a new Sitecore installation all at once, but it requires a manual backup every time.
3) Another way you can use is to serialize your entire content-tree to an xml-format on disk from the Developer tab. Once serialized, you can revert them back into the content tree.
I'd suggest thinking of this in two parts, the first part is backing up the application which is a simple as making sure your application is in some SCM system.
For that you can use Team Development for Sitecore. One of it's features allows you to connect a Visual Studio project to your Sitecore instance.
You can select Sitecore items that you want to be stored in your solution and it will serialize them and place them into your solution.
You can then check them into your SCM system and sleep easier.
The thing to note is deciding which item to place in source control, generally you can think of Sitecore items has developer owned and Content Editor owned. The items you will place in your solution are the items that are developer owned; templates, sublayouts, layouts, and content items that you need for the site to function are good examples.
This way if something goes bad a base restoration is quick and easy.
The second part is the backup of the content in Sitecore that has been added since your deployment. For that like Trayek said above use a SQL job to do the back-ups at whatever interval your are comfortable with.
If you're bored I have a post on using TDS (Team Development for Sitecore) you can check out at Working with Sitecore, Part Nine: TDS
Expanding bit more on what Trayek said, my suggestion would be to have a Continuous Integration (CI) and have automated deploy using Team City.
A good answer is also given here on Stack Overflow.
Basically in your case Teamcity would automatically
1. take back up of the current website (i.e. code) and deploy the new code on top of it.
2. Scripts can also be written to take a differential backup of the SQL databases, if need be.
Hope this helps.
Take a look at Sitecore Instance Manager module. Works really well for packaging entire Sitecore instance.
I am working on a copy of a SharePoint 2007 site for a client.
I would like to be able to automate as much of the update process as I can with minimal disruption to the client's system when the updates are ready for production.
To that effect, I was wondering if anyone knows how to automate creating a SharePoint workflow (created using SPD 2007) in another SharePoint server/site.
Perhaps I haven't searched enough yet, but I have not discovered if there is a way to do this with web services, which I believe would be my preference.
I do not believe I have the ability to use STSadm on this, as the hosting for the SharePoint site is separate.
I think I can export the workflows in a personal web package and I'll admit, I haven't experimented with this yet on workflows, but my current experience with other exports, such as lists, is that guids seem to get messed up between sites. Even if this is not an issue, I'm not sure if there is a way of automating the import process (without STSadm).
I'm hoping not to have to work through a long list of manual procedures (that could accidentally get missed) when implementing these changes on the target production site.
My preference is to be able to create some sort of update batch or application that will make the changes quickly and that I can test before implementing on the production system.
This entails quite a few things, but for now, I'd like to focus on getting workflows into the target system.
Any suggestions on where to get started would be welcome.
SharePoint Designer workflows are not portable between sites. (Reference) 1
For your situation, I would recommend taking the Visual Studio workflow route. Take a look at this tutorial: How to Create Custom SharePoint Workflows in Visual Studio 2008. The key for you is how you will associate it to lists.
The other option is to create a custom Workflow Activity (2007 has less options that 2010). You will still have to create the workflow using SharePoint Designer and add your custom activity to it in each site.
1. Yes, there is the "hack way" of trying to do it by copying the XML and changing the GUIDs... but it is error prone and difficult.
SharePoint 2010 gives more flexibility for workflows and thus the first #Kit Menke statement isn't true for readers using SP2010 (i see that this is tagged as sharepoint2007, but i'm making it clear for readers using SP2010)
However, if you publish a workflow template to a SharePoint site
collection, you can download that template as a WSP file and then
deploy it to other site collections.
Read more about Workflow deployment process (SharePoint Foundation 2010)