Are there any guidelines and best practices for organizing Visual Studio Team Services for a new cloud app? I'm planning on creating a WebAPI solution for REST services, a Xamarin Forms solution for mobile client, an MVC solution for web, and finally SQL scripts. Ideally, I'd like to account for future apps with their own source code.
Dev
App1
WebAPI
XamarinForms
MVC
SQL
App2
...
...
Test
Prod
Another approach is to create a project per App
App1
Dev
WebAPI
XamarinForms
MVC
SQL
Test
...
Prod
...
App2
...
I have also seen people put everything into a single giant project under a single collection. So, instead of creating Dev, Test, Prod projects in the first tree, we'd create them as folders. Same with the second tree. Why would I not want to create multiple team projects?
I'm not a TFS expert, but I'd like to get started on the right foot.
P.S. I've seen a few similar questions on SO but did not think they answered my question, especially the part about not creating team projects.
Visual Studio Team Services (and Team Foundation Server on-premises) support the notion of Team Project Collections, Team Projects and Teams.
A TPC is the highest degree of separation. Currently, you get one DefaultCollection on VSTS. Within this collection you create separate Team Projects. Within a Team Project you have one or multiple Teams.
The current best practices state that a single Team Project is the easiest to work with. In short, this allows you to more easily share code, work items and other assets while still having separate backlogs and code repositories.
For a more detailed explanation see a couple of blogs on this subject such as:
Why You Should use a Single (Giant) TFS Team Project
One Team Project to rule them all
Many Git Repositories, but one Team Project to rule them all
In your scenario, I would absolutely go with one Team Project and then multiple Teams for each separate application. In the top level team you can then schedule Epics and Features and distribute these to the implementation teams.
If I started such a project today, I would also choose Git for Source Control. Git and TFVC are both supported and TFVC is going nowhere. Git however does have some advantages that I think are very attractive.
Regarding your folder structure. If App1 and App2 need to be released together, they should sit in a shared branch. If they can be released separately, they should have their own branch.
The ALM Rangers have a great document on Version Control that explains different Branching models. This is freely available on CodePlex.
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.
background
I've been a religious user for github/zenhub for quite a while. We recently moved our repos to gitlab for many reasons, including free pipelines, security, more flexible groups etc.
Problem
Zenhub is a greasemonkey app that's added to github, one of its features is the scrumboard that's similar to gitlab's native issue board. One of the amazing things about zenhub scrumboard is that it allows you to put many repos on the same board (I recall jira had the same thing).
question
Is there a way to do this on gitlab?
Beside a third-party like kanban.leanlabs.io, recent GitLab releases do integrate a more sophisticated issue management.
See "Announcing The GitLab Issue Board " (presented here)
But it might be limited to only the current repo.
Note that with GitLab 13.6 (November 2020), this is no longer limited to a repository:
Group-level management of project integrations
In GitLab 13.3, we added the ability to enable an integration across an entire instance. With GitLab 13.6, that feature is being expanded to allow integrations to be managed at the group level as well!
Group owners can now add an integration to a group, and that integration will be inherited by all projects under that group. This has the potential for saving massive amounts of time, as many organizations have specific integrations that they want rolled out to every project they create.
A great example of this is using our Jira integration. If you’re using Jira, it’s almost always across the whole company. Some of these companies have thousands of projects and therefore had to configure each and every one of those integrations individually.
With group-level management of project integrations, you can add the integration at each parent group, reducing the amount of configuration required by orders of magnitude!
Read more in our announcement on the GitLab blog.
See Documentation and Epic.
In GitLab issues and merge requests within a group display a collection of issues and merge requests from all projects below them.
And they also have an Issue Board available, which aggregates the issues from the projects within the given group. This is currently not reflected in the documentation, and could be well worth a Pull Request in doc/user/group/index.md and doc/user/project/issue_board.md.
Using this together with group labels and milestones, which also span across all subprojects, you can create the desired board view.
I do use github/zenhub in the past. https://gitboard.co is the zenhub alternative for gitlab. Which shows all your issue and merge request in one simple dashboard across multiple projects.
I have a WebAPI running on Azure WebApps developed with EF Code First.
Now I need WebJobs for some scheduling tasks which should refer to the same DB and Models.
I tried adding reference of the WebAPI project but that marks the DLL as yellow exclamation.
I'm unable to get how should I proceed. Can you please guide me a bit?
As Frederico suggests, you should split your Web API project into multiple projects.
If you isolate the Data Access Layer (EF Context + query) into a separated assembly, it will be easier for you to share the database access into several projects. Moreover you will not have to add reference to web specific dll (for example System.Web.Mvc or System.Web.Razor) into your webjob project.
Anyway you have some yellow warning because your Web API and you Azure web job don't target the same .Net framework.
Right-click on your project then select properties. you should be able to adjust the .Net Target framework.
To be able to reference a project A into project B, the project A should target a .Net framework with a version less or equals than the targeting .Net framework of the project B
I assume that your EF DbContext class and entities resides inside your Web API project. This monolithic approach brings many problems in integration scenarios like the one you shown.
My advice is to modularize your solution and move all your Data Access related classes (DbContext, entities) inside another project which will be referenced by both your Web API and WebJobs projects.
This is a common approach for improving the maintainability of the code and enforce basic software engineering principles like separation of concerns, and is obtained by dividing your application into different functional layers (a.k.a. multi-layered architecture).
If you are interested you can read more about it here: https://msdn.microsoft.com/en-us/library/ee658109.aspx?f=255&MSPPError=-2147217396
I'm new to TFS and we're loving it! I'm having a difficult time figuring out how best to organize TFS from version control and agile/scrum/sharepoint sites, keeping isolation of teams yet sharing of code and projects.
For this scenario let's say I have three teams. Team 1, 2, 3. I want each team to have access to only projects they work on, and each team to have isolation for alerts and notifications, sharepoint, agile, etc. So let's say there are 5 total projects.
Team 1:
--Project 1
--Project 2
Team 2:
--Project 1
--Project 4
--Project 5
Team: 3:
--Project 1
--Project 2
--Project 3
--Project 4
We have one collection setup, DefaultCollection. Right now I only have one team but this doesn't give us good isolation and separation of the features. How can I best configure TFS to keep separation of teams but not have separate code projects? Some projects are shared and this is the point of contention - I don't know how to handle this part.
Acme Widget has X projects and then we have a "Company Shared" with X projects. We may be working on different products such as Acme Widget 1, 2, 3 but all share and work on the Company Shared projects, i.e. Company.Utilities, Company.Windows, Company.Security.
Can someone please shed some light on how to properly configure TFS while we're early into the stages of use. We want to go beyond just version control as mentioned above. We want to use the Task, Bug, Alerts, Build, etc.
P.S. If anyone is a TFS sub-contractor that helps organizations configure their TFS setup I would entertain a professional consultation and configuration.
Since TFS and SharePoint aren't actually holding the user accounts (they are inside Active Directory). It would probably be easiest to create an Active Directory group for each team and place your users in that group. You can then still keep one project collection (no need to over-architect) and then everytime you create a new project within that collection you assign the permissions to that project (TFS, Sql Reports, and SharePoint) using the Active Directory groups. You should download the free TFS Administration tool to manage permissions and when a user joins/leaves a team then you can manage that directly in Active Directory without changing TFS, Sql Reporting or SharePoint. This seems to be a very common approach starting when this issue arose from early SharePoint days when admins were trying to independently manage SharePoint groups and Active Directory groups.
I would suggest that you look at this:
http://blogs.ripple-rock.com/colinbird/2012/11/19/MultipleTeamsWithMicrosoftTeamFoundationServer2012VisualStudioScrumV2xUpdated1452013.aspx
This shows you how you can have multiple teams, which each of theirs board, tasks etc.
We use this in our company because its the same project, but 2 different teams. Then it works perfectly because we have the hierarchy of teams:
-- Project (level 0)
---- Team A (level 1)
---- Team b (level 1)
In that way we can assign stories or tasks to either the one of those, and if they are assigned to the project level (level 0), then it will appear on all teams.
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.