I am very new to BizTalk. I have been asked to create a application in BizTalk. I am facing some design level challenges.
Following are some of them:
Best approach in creating a project
How to crate BizTalk solution. Means how to create projects. Do we need to create different projects for Maps/Orchestation/pipelines and references. Which is the best approach to develop a project?
Can we check in a BizTalk project in TFS
How multiple people can work on a single BizTalk solution? Can it be checked in in TFS and multiple people can take it and work on it? How merging will work?
Code review
Is there any way to review a BizTalk package? What are the best practices?
This is very subjective. I always establish that there is a 1-1-1 App/Solution/Deployment unit. Meaning an Visual Studio Solution should be deployable/undeployable on it's own. No references to other Solutions.
I do not create separate Projects for Schema/Maps/Orchestrations/Pipelines, there's no benefit unless the App/Solution is large...say more than 10 Message Types. Then, it's OK to separate.
Yes, of course. Any number of Devs can contribute to a Solution. The only thing you can't do is Merge BizTalk Artifacts. The Xml definitions are confusing to the Merge tool.
Code Review should be done just like any other project.
Related
I've always been intrigued by Visual Studio Database Projects, and while they seem to be quite capable, I've never used them to any great degree outside of simplistic proof-of-concept work. I want to try this for a new project, and I'm also interested in using an EF layer on top of it, but in past test projects this has involved some decent effort.
I'm curious: has Visual Studio matured its product integration to support a single workflow that builds the database project, builds the EF layer on top of it, and finally builds the code, without intermediate steps involved?
We are a small team and we don't have dedicated SQL developers, and our primary goal is to bring the database into Visual Studio and to get it nicely under source control (TFS), and to achieve strong integration between from end to end. We're interested in growing into EF, and will probably start simple by treating it like a simple ORM tool to begin with if possible.
Has anyone actually done this that can provide insight into the process?
We have used VS2014, tool seem much the same and early version
Don't think has been much changes over the years
We have EDMX model and a DB project in the solution
Does mean that you need to keep the db project up to date.
But this is easy to do, you just publish you EDMX to local box/target
Then can import the changes with a schema compare of local to the project.
So they you can still have Model driven DB design
And use the DB project to deploy changes to the Dev/Stage/Live boxes
And can publish with automated deployments also.
The db project has a post build scripts option
Where you can use it to do seed data
And also a pre-build where you can do db manipulation if need to change structure and types of fields types when the data is on a live db.
Schema compare tool are rather good in Visual Studio
Can compare a DB to DB, DB to Project, or Schema file to either also
We have Team Foundation Server 2008 deployed as our source control management system. A team that is responsible for multiple products is asking for all their products to be put under a single TFS project. Their reason is because the products are all in a similar domain.
Here are my reasons against:
The workspace mappings will get weird, since projects will be mapped to subfolders
Continuous Integration may be a problem, since a single project can't be referenced
Tracking history of source control activity could be problematic
This just feels like an overall bad idea, but I would like some concrete reasons against it. If I'm completely off-base and this is a good approach to take, I'd like to hear that as well.
What are the pros/cons?
I have experience storing multiple Visual Studio Solutions (seperate products) under one TFS Team Project in both TFS2008 and TFS2010. Here is my take.
In both versions we create a folder for the Product, then a folder for the branches (Main, etc.) This makes it easy to see what product we are working on, and we can see the history of the product seperate from other products. Continuous integration works just fine with multiple build definitions, one for each product. We only create one workspace mapping for the entire TFS Team Project.
The shortfall in TFS2008 is that it can be difficult to manage work items for each Product. In TFS2008 the work items apply to the entire Team Project and it is not as easy as it should be to figure out which work item belongs to which product.
In TFS2010 the work items have an Areas and Iterations section. We use the Area to define the Product. So each Work Item gets an Area that matches the Product name. This has worked very well for us.
If you are not using work items heavily in TFS2008 than I don't think you should avoid putting multiple Products in one TFS Team Project, certinally not for the reasons you listed above.
Using one Team Project does haves some advantages:
1. There is ony one Team Project to manage and there is only one Share Point site.
2. You can see history across the entire Team Project easily.
My thoughts:
If there are assemblies shared amongst the projects, it makes sense to lump them together, otherwise you will run into the same problems that many people have discussed here, on how to handle shared assemblies.
You shouldn't encounter any problems with workspace mappings. Within our organization, we simply map $/ to a folder and go from there. Otherwise you could very easily map individual source control folders to different areas on disk. The only recommendation I would have is to put that mapping in a batch file, so that new members can run the batch and be consistent.
The only thing that you might lose out on a bit by lumping these all together is quick and easy reporting. If everything is in its own Team Project, the built-in reporting works "out of the box." If you put things together, you'll need to set up additional areas and iterations in order to do the reporting and tracking.
In our organization we have upward of 15 separate team projects, but every single one of them has more than one "product" underneath. We've been running this way for two years and really haven't had any problem with it, with the exception of the reporting.
Using a single Team Project for more than one software is a perfectly acceptable solution if you don't use separate templates for them. Martin Hinshelwood has a detailed blog post on the subject.
http://blog.hinshelwood.com/when-should-i-use-areas-in-tfs-instead-of-team-projects-in-team-foundation-server-2010/
This is a follow-on post to our previous post (Help Structuring VS2010 Solutions/Projects and TFS2010).
We have a few questions regarding how to structure our VS2010 solutions and projects for best organization, as well as to save in and use TFS2010.
Currently, our code is structured something like:
/OverallAppName
OverallAppName.sln
-/Client
- -/WindowsFormsProject1
WindowsFormsProject1.sln
- -/WindowsFormsProject2
WindowsFormsProject2.sln
-/Components
- -/ClassLibrary1 (common library referenced by other projects)
ClassLibrary1.sln
- -/ClassLibrary2
ClassLibrary2.sln
- -/ClassLibrary3
ClassLibrary3.sln
- -/ClassLibrary4
ClassLibrary4.sln
- -/ClassLibrary5
ClassLibrary5.sln
-/Server
- -/WindowsServiceProject1
WindowsServiceProject1.sln
- -/WindowsServiceProject2
WindowsServiceProject2.sln
- -/WebProject1
WebProject1.sln
- -/WebProject2
WebProject2.sln
Since, right now, we’re in the process of moving from VSS to TFS2010, we’re wanting to structure all our solutions/projects to be most efficient, most logical, easiest to maintain, easiest to reference, and easiest to use with and build in TFS2010, and we’re needing some advice on the “best” way to structure everything with a partitioned solution model.
Any suggestions????? How can we structure all these different types of VS2010 projects into a logical structure that separate groups can work on individual pieces (not the entire solution), we can still have project references, we can stored in TFS2010 and build and branch in there, and follow “recommended best practices”?
Thanks.
(Sorry, I'm not sure the formatting came out very good.)
While I admire your commitment to trying to keep everything as one large solution, I think this is going to defeat some of the best features TFS has to offer in the realm of automated builds by sticking to this.
The reason I say that is because you can use builds triggered by check-in to immediately build the code to prove it works (or better yet, use a Gated check-in). The usefulness of these builds are inversely proportional to the time they take to run. So if you have a massive solution that takes 20 minutes to build then it's going to take away from the advantages of those types of builds. If however you had several smaller solutions that took about 5 minutes each then you'll only get the modified solutions building on check-in and know the results sooner.
From what you've listed above I'd be inclined to have a solution for each set of artefacts that can be released separately. In your example that's probably one for each of the clients, one for each of the web applications and one for all of the common libraries.
Folder structure wise it'll not be much different to what you have above (assuming I'm interpreting it correctly)
/OverallApplication
/Clients
/Client1
-Client1.sln
/Client1Project1
-Client1Project1.csproj
/Client1Project2
-Client1Project1.csproj
...
...
/Components
-Components.sln
/ClassLibrary1
-ClassLibrary1.csproj
/ClassLibrary2
-ClassLibrary2.csproj
...
/Server
/WebApp1
-WebApp1.sln
/WebApp1Project1
-WebApp1Project1.csproj
/WebApp1Project2
-WebApp1Project1.csproj
...
...
/CodeSigningKey
-KeyPair.snk
/ReferencedAssemblies
/Manufacturer1
-Manufacturer1Assembly1.dll
...
...
The common libraries can still be added as project references in the server and client solutions. I've introduced a few new folders for common items such as the code signing key and 3rd party assemblies that are referenced (such as the Enterprise Library).
On top of that you'll want to employ a branching strategy of some kind to keep Main, Dev and Release code branches separate. I recommend a little light reading of the ALM Rangers branching guide on codeplex for that.
http://vsarbranchingguide.codeplex.com/releases
Following SO thread shows Managing DLL references in multiple projects across different solutions. Additionally I want to know how to manage the version control for these dependency DLLs ?
Should the DLL (which is published to other external projects) be committed too, every time code change happens ?
Team Development with TFS Guide (Final Release)
This guide has proven to be invaluable to my team. They describe several scenarios and what the pros and cons are of each. For anyone managing a TFS environment this is a must read.
With regards to the DLL's from external projects. We will keep a copy of the source in TFS if we can get access to the source some times, use your best judgement. We keep a copy of the DLL in source control always. The DLL goes into a "SharedBinaries" folder next to source code so that they can be branched together.
It is critical that you be able to branch these DLL's along with source. It is also critical that they be in TFS so that you can do an automated build with little or no build machine configuration. My own personal goal while managing TFS is to be ready for a new developer to join the team and with a single get of source code be able to execute a successful build for local debugging.
EDIT: Different department builds DLL
Like all good IT answers I have to start with "it depends". If the other department is truly segregated from your department and you have little or no knowledge of what they are working or when they will be working on it. If they just occasionally tell you that they have done some things and you should now incorporate the changes then I would lean towards the DLL being committed to the repository every time that the department consuming it wants to change it.
If on the other hand we are really just talking about different teams in the same department where there is lots of cross talk and water cooler communication then I would expect that you could making something else work with just some project references.
It sounds to me like it is the former and not the latter situation that you find yourself in today. I would try to get the department that is creating the shared code to "release" the shared code like Microsoft releases the .NET Framework. Get them to just build the API and give you some DLL's and some documentation. Then the groups that are incorporating those DLL's into there products can check them in separately into a repository of there own control and isolate themselves from code churn while the department working on the these reused DLL's can work on the next version of them.
You should take this all with a grain of salt. This is just one guy rambling on about what might be a good idea. There are many more ways to solve these problems and they are all correct given different circumstances. If you are asking 5 people and you get 5 different responses I wouldn't be surprised.
My team is developing WCF services in Visual Studio 2008 SP1 with the Service Factory Modeling Edition. The problem is that we have so many services to develop and we've put everything in the same solution.
250 projects later, the solution barely loads and adding to it is nearly impossible. We thought it would be good to split out every service into its own solution, but the service factory stuff effectively prevents us from doing that.
We are generating code from our model project into our other projects, but if we try to use multiple solutions, we can't reference the model project because it can't maintain the project mappings it needs in order to generate to the proper location. And we use a couple shared data contracts in our Model Project, so splitting the model project up doesn't seem to make sense either.
We have so many projects now that we can't really turn back and not use the service factory method of doing everything.
What should we do?
At this point you should break up your 250 projects into groups and create a solution for each of them. My recomendation is to use ~25 projects per solution. Use these mini-solutions for your day to day editting.
It is still possible to do a full build of the overall solution via msbuild and the command line. But VS was not meant to handle so many projects at the sametime.
I'm surprised to hear you say this. I used the Service Factory in my previous job, and we created a separate solution for each suite of services. In each solution, we created one or more models in the model project.
I recommend that you experiment by creating a couple of new SF solutions, adding a couple of models and generating code. See if that causes any problems.
Have you discussed this or created an issue on CodePlex?
I agree with John Saunders. Keep them small. Also, keep a Continuous Integration env running to keep track of your mess-ups during development.