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
Related
I am used to working in a team that uses Web Forms and VS Source Safe, so procedure would be something like:
get latest version at beginning of day and before checking out.
check in all files at the end of the day, and notify team not to upload.
when finished the page and ready to upload, take a backup, just upload your files and check in.
the team was small enough that it was manageable.
Since you precompile in MVC and Web Applications, it is not possible to upload the site whilst pages in development are checked in.
What is the normal procedure for deployment in small/medium/large companies?
Thanks.
There is no normal procedure, although by rule-of-thumb it generally gets more complex and convoluted the bigger the company.
Consider your own process, if there is nothing wrong with it, then don't change it.
If you need to expand your team, consider a more collaborative way to manage code and deployment. Deployment sucks and nobody wants to do it manually over and over, verbally telling people you're uploading and not to is even worse > consider a build server such as TeamCity or TFS and setup a deploy process that manages this for you.
Consider moving from SourceSafe to Subversion, GIT, TFS etc.
Research ALM across the web (there's lots of good shared knowledge on blogs), but again, consider your need first, and think about if any changes will be actually cost effective and gain you productivity.
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.
I'm interested to find out what would be the good way to make changes to production database and source code in web application (ASP.NET, SQL Server 2008).
A little bit more details, we develop on local machines, and then we need to transfer the code and database changes to production (pretty much standard story).
At the moment we do it in the evening, change the database directly from management studio on production server, and then just overwrite the existing asp.net code (copy/past).
You're talking about Release management. What you're asking about is a big subject with a LOT of different answers. The best solution for you is not something we can tell you. There are trade offs to consider.
For example, what you're describing is a very basic release management process that would be considered an "immature" process.... It does not take into account rollback plans, versioning, separation of concerns, proper testing, or any of a hundred other factors that a "mature" release management process involves.
A mature process is very good, but if you don't have the resources, it's not feasible.
To get to the point, I don't think you question can be answered fully here. I'd suggest starting to research "change management", "release management", "Application Lifecycle management", and "Applicaiton Development Lifecycle". I'll have a few good starter links for you in a minute.
Just a forewarning, though, you are asking a question that's going to open your eyes and your world in ways you probably haven't considered. There are things like automated builds to consider, tools to do it for you (high priced, free, and everything in between)
http://en.wikipedia.org/wiki/Release_management
http://en.wikipedia.org/wiki/Application_lifecycle_management
A few simple options for JUST what you're asking about can be found here:
http://msdn.microsoft.com/en-us/library/7hd4c0x3(VS.80).aspx
Also, since you talked about source code without mentioning which source control you're using, I need to say... if you're not already using source control, you need to. You'll wonder how you ever lived without it once you start using it.
Depends on whether it's the first deployment of a new app, or an update to the app.
For small updates, record all your database changes as sql scripts. You must strictly enforce that all changes to development are applied as sql scripts. Put the scripts in source control. Deploy the update by running the scripts on production.
For new apps you may have thousands of scripts. You can't run them individually. Consolidating them into a master script takes too much time. (although you still want to check EVERY script into source control). In this case you reach a milestone in development then FREEZE the development database, and declare it a baseline. Use the database tools to generate a master script(s). Deploy production by running this script(s). Manually create data scripts for your lookup tables to keep it separate from junk dev data.
Avoid a database copy. Avoid changing by hand through the GUI. Scripts are the way. How you go about collecting the scripts, consolidating to master scripts, generating the scripts, etc is another story.
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
What is the simplest way to distribute an asp.net web application? I tried to look at some of the open source asp.net projects out there to see how they distribute their apps and how they do updates and they seem rather complicated to me (not for myself to perform but for non-technical users). A lot of them entail backing up the entire installed project, deleting specific folders and save parts of their web.config. I am hoping to find a solution that will make the update process specifically as simple as possible.
Thanks.
I am working on a project with a similar requirement now. We decided to use WiX to create an installer that can be run on the server or machine where the site is installed. WiX is incredibly powerful, but takes a bit to get the hang of.
There are plenty of other open source, and paid installer technologies as well. Here is a post with some info on a few.
CommunityServer provides a setup msi that will create a virutal directory, generate the SQL database and populate it with default data. Updating for point releases though is still a manual process involving an update.sql file and having everyone download then merge binary and static file changes.
They probably could have created an update msi too, but because so many people customize CommunityServer, it is probably better to let people merge changes themselves.
Do you mean in terms of breaking up the functionality into tiers that could be handled on separate machines, e.g. having 3 servers for a 3-tier architecture where one is the DB server, one handles middleware and the other handles the requests in ASP.Net? Another point here would be in going from a web server to multiple web servers in terms of scaling up.
Or are you referring to deployment?
It's a web application, man. Serve it publicly, require registration, and move on. Isn't that the point of the web application?