Our company has decided to start using Team Foundation Server 2010 for our development process.
I am having trouble deciding on how to structure our Collections and Team Projects.
We have a total of 9 developers, all working on different projects at different times.
It seems like half of what I read says to use as many collections as you want, while the other half says to limit the number of collections.
What is your approach when creating/managing several projects that don't necessarily interact with each other? Is it best to put stuff in separate collections or is it wise to keep the number of your collections low? Any help is appreciated.
I personally wouldn't muddy the water with a lot of collections here. A default collection with a Team Project for each thing the developers would be working on would be fine.
Each "Default Collection" is kind of like a separate instance of TFS (running within the same environment). The idea is that collections don't cross over each other, and all of the data always stays separate. If I recall correctly (can't test right now because we're still on TFS 2008), you would actually need to switch out of one collection and into another to start working in that collection. I don't believe you can have two collections open simultaneously.
My stock answer for this question is that Team Projects should mirror the lifecycle of you projects. For example, if you have customers and you do projects for customers than I would create a Team Project for each customer project ... Even if it involves the same source code as another project.
For in-house development the lifecycle of a given application is typically "forever" so I'll see them using a Team Project per line-of-business application.
The only reason a shop as small as yours would want to create additional project collections is if you needed that level of isolation. Some reasons include: 1. You have a legal or regulatory reason ro keep source code and work isolated (government, privacy, PCI, etc). 2. You have customers which want their work items and code delivered to them at the end of the project. Some may want the history so it is nice and easy to give them their own project collection instead of having to sort through others' data.
If you need more info, it may help to post what the nature of the projects are.
Each collection requires a separate Build server (and license), so you should consider that in your planning. One Build server, one Collection.
Related
We would like to manage a project structure where individual projects can take a part in a top level project structure sharing a single resource pool. It should be possible for individual authors to work on those individual projects, or possibly the same project, at the same time.
We are familiar with co-authoring in excel, word, etc (through sharepoint) and it works fine. We have licences for MS project 2019. But we can't seem to find a way to set up co-authoring, or find any definite statement as to whether it is even possible with project.
I have seen "Microsoft Project Server 2019" and "Project Online" mentioned, are these different products and are these needed?
Any guidance or info about this would be much appreciated,
Project Online is the Azure based version of the good old Project Server for on-premises. Both are so called Enterprise Project and Portfolio Management Tools. If you are looking for co-authoring in sense of concurrent editing, you will not be satisfied with both of them: You must checkout and checkin a plan for editing. If you are looking for true concurrent co-authoring you should take a look at the oncoming new Project Service. It explicitly allows co-authoring. Nevertheless it starts with very limited features, it is supposed to grow soon and fast.
https://www.microsoft.com/en-us/microsoft-365/blog/2018/09/25/a-new-vision-for-modern-work-management-with-microsoft-project/
https://techcommunity.microsoft.com/t5/Project-Blog/A-letter-to-our-Microsoft-Project-community/ba-p/260891
Team A has an enterprise app that uses ADO.NET for data access that executes stored procedures. The data access is encapsulated in it's own project (let's call it DAL.dll)
Team B is creating another unrelated app that's reusing the stored procedures in the enterprise app. This app is currently using the MS application block for data access. The issue we run into is that whenever Team A make any change to the input/output params in the stored procedures, there is a runtime error in Team B's app and this app needs to be updated to accommodate the additional params (or params that were removed). So, most of these go unnoticed until a user complains. At the very least, we would like to have the app throw a compilation error so that the build process warns us of the changes made.
One way to do this is to have Team B's project add a reference to the DAL.dll
I'd like to know if there are any other cleaner ways of solving the issue. We are ready to replace Team B's MS Data application block to use a different technology (Entity Framework?) if necessary.
Among the other answers, I'd strongly suggest getting those stored procedures into source control, in a Database Project. You then may be able to use the features of your source control system to do several things:
Lock some of the code so that it cannot be changed
Give you notifications if the code is changed
Warn you if the stored procedures change in a way that would prevent them from being called
Branch the stored procedures so that each team can have their own version of changed code, while keeping the unchanged stored procedures common. You of course will need to separate the different versions in the database.
I agree with the other posters on this thread that you should not share stored procedure's across different .NET DLL's, that is just a recipe for disaster. I would also shy away from ORM's like Entity Framework if you are doing anything at all complicated with your database schema because ORM's excel at getting a simple object model translated from your .NET application classes into SQL tables and SP's, but traditionally do poorly at optimizing them for performance on the database side. There will be people who claim otherwise, and they may have a valid point if you are an expert in wrangling an ORM to do waht you want like they are, but chances are you are not and it will cause you headaches in the long run.
A shared data access layer might work, but conceptually you are then just changing the implementation of the dependency from some code that a DBA wrote to some code that a .NET programmer wrote. Yes, you can use integration tests to achieve better verifiability, but the same case could be made for SQL with tools like Red Gate's SQL Test. I would shy away from this approach if the two applications are already experiencing some sort of pain from sharing SP's. That is an indication that the dependency just should be done away with.
If it were up to me, I'd just make a new schema for Team B's app. You can read more about schemas in SQL Server here: MSDN Schema description for 2008 R2. You can think of them as namespaces for SQL Server but with some additional bells and whistles like permission and access control. Separating out your different applications into separate schemas on the same shared database will probably make for the most flexible implementation in the long run.
unrelated app that's reusing the stored procedures in the enterprise app
If these two application are really unrelated why are those sharing procedures or even the same database. I know this is a long read, but I recommend you to read this: A Better Path to Enterprise Architectures
The partioning concept in there relates to the bounded context in Domain driven design:
Multiple models are in play on any large project. Yet when code based on distinct models is combined, software becomes buggy, unreliable, and difficult to understand. Communication among team members becomes confusing. It is often unclear in what context a model should not be applied.
Therefore: Explicitly define the context within which a model applies. Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas. Keep the model strictly consistent within these bounds, but don’t be distracted or confused by issues outside.
It is expected you end with problems when you don't explicitely deal with this. You're lucky you're seeing early failures, as it can turn into problems much harder to find on the long run.
Analyze the problem again with the above in mind. Consider if you're missing some explicit context where this common functionality should live.
My question is: which team owns the store procedured and the database shared? Usually as a good architecture/design, you should not have two different apps sharing same database / procedures.
A better way to share data/functionality between two different applications is through a services or API, so the team who owns the functionality would be responsible to maintain it.
Also, have a good communication between both teams is highly recommend.
Depending on the owner of the DAL project, you could host web services and share the API. That way, you separate the Data Access Layer from the business logic, which allows anyone to use the same DAL without having to publish it to each different location.
From my point of view, it looks like both Team A and Team B should share the same core model and look at Multitier architecture as a possible solution.
It sounds like it would make sense to create a shared DAL that both applications can share.
I would add unit tests (or really integration tests) to make sure the DAL is compatible with the apps after changes. That way your tests would fail if incompatible changes have been made
"I'd like to know if there are any other cleaner ways of solving the issue."
The cleanest way is for Team B to sit down with Team A and encapsulate the relevant business logic into a shared API. It doesn't matter so much how you implement that API; what does matter is that the API's interface is documented and versioned so everyone knows what to expect.
One reasonable mechanism for this in a .NET environment is to use Microsoft's WebAPI.
In short, the question of "how do we share a stored procedure?" is most likely looking at the wrong level of abstraction.
Is there any specific way to divide any ASP.NET project between the team members?
I am working in a team and all of us (the team members) are new and each time we have a difficulty with dividing the project between us.
This is somewhat open ended not knowing your environment, skills, type of project, etc. but a 1000 ft view:
Split the application out into separate components. If you are using TFS one user can shelve their pending work so the others can use it and compile OR you agree to code to particular interfaces which you can mock the data on until another team member is done with their component. Since the interface is generally quick to define, you can immediately start using it and generate a stub class to implement it until the work is done.
My team also working on Web Application project. We all are working as
a team using Repository We are using VisualSVN. Using svn, Team
members can use working copy of repository modify their part and commit or update
the changes.For deviding project, some will work on back end
coding(database, stored procedures, webservice etc) and some will work
on front end(Design and coding of master screens etc).. Main thing is
Clear communication between team members(Ex:use Skype), discuss about
project and divide work based on member's expertise and interest
of work.
I am trying to think about a web application development framework for our product development. I want to build an ASP.NET application which has many sub-modules in it. My requirements are like:
The application will be a suite of different modules like CRM, Bugtracker, Inventory management, Finance management etc.
Each Module should have their own DLLs.
One project should be for the external container of the application (like the framework) and this project should bring all other modules (of type web application) in the solution to the external container. (Some thing like we have Frames in HTML). So we will publish the external container web application only at the end of the day and all other web application projects will be accessed via that.
I would like to have separate DLL for each module so I don't need to fear about the application breaking when I am deploying my single DLL which controls the entire suite.
I am not sure whether my thoughts are in the right direction. The end result I am looking for is a well-maintained, organized, and modular web application suite.
It is ASP.NET web forms, not MVC. I will use VS2010 for development.
What are the best approaches to do this?
Edit:
The term external container means it acts like a master page which has links to various modules and the various modules are not always in the same project. They can be separate project under the same solution. And I am under the impression that, by the end of the day, I will publish that project only and it will bring the various modules to it.
I actually think the best approach would be one that does not over-architect. I'm concerned that it seems you are producing an overall architecture without sufficient reason.
Are these all new modules? Then just start writing the first one. Use best practices that apply to single modules.
Then write the second one. You'll find you want to use things you already wrote in the first module. Great. That's what refactoring is for. Refactor these things out into one or more "library" projects, re-run all your unit tests, then proceed with the second module.
Repeat until all modules are done.
At the end of this process, if you needed the kind of architecture you've outlined, then you'll have it. If you needed less, then you'll have less, and you will not have spent time creating an architecture which is not tied to real-world requirements.
I'm not going to say this is a "best approach" but I would recommend looking over Dot Net Nuke (DNN) to get some ideas. This started as the old "I Buy Spy" starter web project that Microsoft distributed to show ASP.NET projects, and it took off from there.
edit:
1.The application will be a suite of different modules like CRM, Bugtracker, Inventory management, Finance management etc.
You can do this with DNN. They're also called "modules" in DNN and Drupal.
2.Each Module should have their own DLL's.
Yes, this is a good idea. And you'll see this sort of thing in several content management systems like DNN and Drupal. This way not all implementations of the same website need to have all modules installed.
We have a significant website that is used to host a "service as a solution" application that we charge for (if you aren't an actuary or accountant you won't have heard of it). The lead developer for the past couple years used an earlier version of DotNetNuke as a model for how to refactor the parts of the application that he was allowed to change.
Like others have suggested DNN would probably work for what you're trying to do. If you want to completely roll your own naturally I would turn to some sort of combination of a container "Framework" and a bunch of user controls (.ascx). The container could be as simple as a master page with a menu. Depending on how flexible you want your design you can prefabricate many different pages, each hosting a different control (separate dll as you wish). If you want it to be a little more dynamic you can have one content page that will dynamically load at runtime the desired user control into it. Again this is just a general approach, probably a 30000 feet view into how DNN is implemented anyway.
Name the main project after your company/product and keep it short and simple. You will probably need one or two library projects to support it - these will contain everyday, common logic for such things as error reporting, Web utility methods, etc.
Next, pick one of your intended sub-projects (I don't like the term module in this particular context) and add that to your solution. Whether you are reusing an existing project, or preferably starting from scratch, you will eventually have any common logic in this project moved out to your libraries.
Rinse and repeat. Perhaps take a look at something similar like the Sueetie project which includes several sub-projects like CMS, Blog, Calendar, Forum, etc.
The following article is marked as "outdated" on MSDN but I still think you should take a look at it:
Structuring Solutions and Projects
Also, something similar from the Patterns and Practices Group:
Structuring Projects and Solutions in Team Foundation Source Control
Say you have a large Web site, containing several discrete applications that run in the same site to do various things. You don't want to manage everything as a single project, so you break them apart, work on them in total isolation from one another, and just deploy them separately into the same runtime environment.
These applications will run in the same process. No virtual directories or app isolation. They will share things like session, cache, cookies, etc.
Sure, the code-behinds and class-libraries are just DLLs in the bin folder, but what of the presentation-level stuff that has to integrate in the runtime environment? What about sharing of the code-level resources I mentioned above -- cookies, session, cache, etc.? What about base page classes?
Example: it strikes me that every sub-app needs to be "master page aware" -- it needs to know where the master page will be located, and what ContentPlaceHolders are available, because the sub-apps Web forms will need to reference this stuff.
Any other thoughts here? Assume the sub-apps will share the same master page, theme, and everything else in the presentation layer, so they appear to be a seamlessly integrated part of the whole. But they will be worked on in different Visual Studio projects, by different dev teams that know nothing about one another except what's absolutely necessary.
Anyone want to share some best practices here?
You don't want to manage everything as a single project, so you break them apart, work on them in total isolation from one another, and just deploy them separately into the same runtime environment.
Why work in isolation? Establish a repository for the entire solution including all projects. Whatever change is made it is immediately available to all developers. With your approach it will be a nightmare to come.
Consider splitting responsibility by pages. One team does one segment, the other does the other one.
Another option is to let each team develop their part as a user control. You can easily assemble those together to represent a complete product.