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.
Related
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.
Working with a large team, we often use SharePoint and TFS to deploy and store our code, documents etc. However, Why do we use SharePoint in some places and TFS in others. Please explain the criteria and the basic difference between the two.
Thanks!
SharePoint is a document management system that has support for lists.
TFS is an Application Lifecycle Management tool. It provides SCM(Git or TFVC) as well as Work Items (effort management), agile planning tools, test tools, build tools, and release management.
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 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
I am total beginner in SharePoint and I need some help in starting a project. I have to develop publishing site that will be delivered to the client. I would like to give client deployment experience like he would get when deploying standard ASP.NET application as much as possible. I plan to use Visual Studio 2008 with SharePoint extensions and maybe WSPBuilder or some other tools.
I also need help in structuring whole project.
Here is what I plan to do:
1. Develop minimal site definition
2. Create site from this defionition. How should I do this from code ? Use SharePoint Feature ? How should I activate it ?
3. Develop all the needed infrastructure for the site (master page, layouts, content types, ...) as SharePoint Features.
Is this correct and how should I develop all those parts so I can make a some kind install script so can client create get complete site with one click ?
Site definitions are complex no question about it, but they are very useful if you need to deploy to unrelated enviornments. If you are staying on the same server farm, maybe site definition is overkill. If you are going between domains (i.e. test & prod, then maybe they are worth looking into).
Another advantage to site definitions, esp. if delivering to a client is it feels more like a traditional deliverable. They will have a bunch of files (hopefully in source control) that are their custom site. I think that gives IT dept's a much warmer feeling than an XML file created from the SharePoint UI.
Another benefit of site definitions are you have a lot more control over the pages that make up the site. IMHO its easier to add master pages & custom CSS via site defintion that site template.
I am curious as to what are the 'moving parts' to the site you are trying to deliver? I think that answering that question will determine how to define the project's structure.
Generally, I think you are on the right track. Features and solutions are a must. I would stay away from VSeWSS, its buggy and clunky and generally terrible if you are trying to do anything complex. It tries to be so smart, that it leaves you no control.
That said, it really depends on what you are trying to do. If you are going to build a solution to deploy to the GAC with one assembly, and only building features supported by vsewss you may be fine.
If however, you want to develop, say a timer job wiring that into the VSeWSS feature framework gets tough. Also, if you need multiple assemblies in the solution. YMMV, but I had to junk it and find of a more flexible solution (hello NANT).
A lot of the work you will end up doing is building and checking, and re-checking XML configuration files. Bookmark the Feature Schema reference page on MSDN, you will be spending a lot of time going through it.
Finally, yes, if you have all of the parts packaged as features you should be able to develop a nice install script. Ultimately the script will need to call the STSADM (there are some really nice STSADM extensions here) commands necessary to create the site structure, add & deploy the solution & activate the features. You can start with a batch file, and get as complicated as you want.
Personally I don't find that creating a site definition is really that useful for the sites I have built. They can be very tricky to set up, because of their complex nature.
What I do is use the standard Publishing Site and then using features to add my additional componets (deployed via a SharePoint solution).
You can use Feature Stapling to connect up the feature to the Publishing Site creation.
I've also just done a blog post on how to programmatically modify the workflow which is created by default: http://www.aaron-powell.com/blog/february-2009/programmatically-modifying-sharepoint-workflows.aspx (that also has a link in the comments off to the Feature Stapling concept).
Then I use a combination of SharePoint Solution Installer (http://www.codeplex.com/sharepointinstaller) and batch files to install the components. SSI for all the SharePoint database level installs and batch files for the file system stuff.
Adding another answer, because I have more than 300 characters worth of stuff to say :(
RE: SharePoint solutions generator, again I would say your mileage may vary.
The biggest issue with SharePoint dev is managing all of the "magic strings" across the various configuration files. GUIDs and Fully Qualified Assembly names are the spit and glue that hold the whole thing together, and although it all makes sense its very difficult to manage.
The current crop of tool all try and alleviate the complexity of managing these things, but they require that you work in a certain way, so the tool knows how to inject the appropriate plumbing.
If you plan on doing a lot of work with SharePoint it really behooves you too learn to manage the plumbing yourself. Its painful up front, but really pays dividends.
Basically, I suggest you spend your time learning the platform and not the tools. Once you know the platform, using the tools will be much easier.
If you are doing this as a one-off engagement and just want to get it done, I'm sure you can get any of the tools you've mentioned to do the trick.
I would agree with the use of the out of the box publishing site definition, and then customizing it using Site Collection features (Master Page, Page Layouts, CSS) and site features (create lists, pages, sub sites, defining master pages of sites, etc...).
Feature stapling is great when you want to customize new sites (allow user to create new sites) of well known site templates, like customize the "My Site" look and feel. In this case I don’t think its very useful.
As a tool to help this task, I personally use STSDEV (http://www.codeplex.com/stsdev) to help in creating, programming, debugging and deploying my Sharepoint solutions.
First it creates a good project for Visual Studio (clean, or with some nice "starting point" definitions). Then it includes some “build configurations” that really helps with install, deploy and upgrade in the development machine.