If we have 3 developers working on the same Biztalk project what is the best way to set up our development environment?
We are using TFS to store the Biztalk project.
Should we use 1 sql server and 1 Biztalk server and then have 1 or more developer machines that access the sql and biztalk servers? The issue we get with this is when 1 developer compiles and deploys their changes it can effect other developers if they are also trying to compile and deploy their work.
Should we have each developer host their own complete sql and biztalk server for local development either on their machine or within their own virtual machine? The problem we find with this is that each developer could modify their server settings and those settings are not stored in source control. This can cause confusion when changes are deployed to a testing server. Another smaller issue is that each developer would need to have sql server, biztalk server and windows server installed.
Is there another way to set up a multiple developer biztalk development environment?
You will always want to have each developer have a complete BizTalk installation on their own machines. Believe me, it doesn't work otherwise, as you'll just keep getting on each other while trying to deploy/test/debug changes.
That said, you will also want a centralized dev/test environment where you deploy your code for more complete integrated testing and making sure all the changes from everyone are seen together.
Your point about configuration is true, but only up to a point. This is because you should make your solution configuration part of your source code and keep it in source control as well. This is particularly important once you're a bit ahead in your development as you'll need to start maintaining multiple versions of your binding files for each environment (dev, test, production and so on).
tomasr is right. Also, if you have decent hardware and lots of RAM, you may want to setup a VM image of your full developer environment, then share this will all your team. Not as fast as native hardware, but does allow you to roll back changes, replace your VM if you really mess up and everyone then has the same environment – ideally close to the target one.
Setting up a continuous build server is also a most, if your projects are small, you can get each checkin to cause a full build, BizTalk deploy, export of MSI and then run tests. Later as your solutions get more numerous you might have to move to a continuous build of C# changes only, then say nightly or several times a day, you do a full. We have done this with CruiseControl.net, Nant, nunit and various power shell scripts, it was pretty time consuming, but each morning we come to work to find a fully compiled, deployed, exported and tested set of BizTalk solutions ready for the test team.
Related
I originally felt this question was for Software Engineering, but they've closed it as off topic and sent me here, so here I am.
One of the biggest time sinks when doing the odd piece of DB development is setting up the environment locally, often my process goes like so:
Get database
Publish db server
Publish db
Load test data
Repeat for any dependencies (can go 3-4 levels deep)
This is a bit of a pain really, and can take a while, and I was thinking if there are any ways to automate this.
We make use of ADO, and through ADO we run builds that deploy our changes and load out test data to make sure we haven't broke anything. Now I imagine ADO follows a very similar process to myself like above, and reviewing the build it looks something like so:
Now, I'd love it if I could get access to the script that runs this, so that when I start development, it gets rid of all the above down-time of setting up the environment.
Does anyone know a way to do this? Or perhaps have any other recommendations?
No, it's unable to copy the build to run locally. They are all based on the existing tasks (see Build and release tasks and azure-pipelines-tasks ).
However, you can try to develop your own scripts by calling the corresponding tools for each step, then combine them together.
Alternately you could setup a private agent on your develop machine, then you can build with this private agent with that build definition.
Another way is setup a on-premise Azure DevOps server, thus you can export the definition from your Azure DevOps Service and import to the on-premise Azure DevOps server to use the definition directly.
I am initiating a huge team to use SSRS for their reporting purposes. Previously I used to develop the reports and send it across to the DBA to implement it, but my recent posting is into a company where they Build once and deploy many process.
I would like to know how reports I developed on DEV environment be pushed into the upper environments with an automated build process.
Thanks
I had a engineer design our .net application back in 2009, my guess is that it was coded using visual studio, and all I have is the installer application. We have been using it on our 1 or 2 local client machines very well for the past few years, but now I want to move this front end to the cloud. Instead of installing it as an application on our windows 7 machines.
It is a very simple application used in our small warehouse that keeps track of cargo/shipments etc. It uses Sql Server 2008 Express as a backend which is stored locally.
I know how to get the database in the cloud, their are many options for that, using Amazon or Azure, but how do i get the local client application to the cloud?
I dont have access to the visual studio code, i just have the runtime executable file..
I am sure there is no way to do this, and many of SO users will say i need to re-write the front end.
I have tried to contact the developer and they hav since closed down. Is their anyway i can run this in the cloud?
I welcome all options and solutions!
Thanks.
I believe you have two options for hosting this application:
If you are able to configure the database connection string, you could host the database in the cloud, and distribute the application to your end users. However, you've already stated that you know how to move the database, so I assume this isn't an option.
The only alternative is to run the entire application on a cloud server, and send the user interface to a client using terminal services. This makes it appear as if the application is running locally on the user's computer, while it is actually running on the server.
For an off-the-shelf solution to achieve this, you could consider using Microsoft's RemoteApp Azure service. I'm sure there are other similar offerings available.
I've been following Microsoft's guide for installing a dev environment on Windows 7:
http://msdn.microsoft.com/en-us/library/ee554869.aspx
In order for it to not run like a dog I've created a SQL Server 2008 instance on our database server specifically for this dev machine. The article does mention that you might be wanting to use an external database in regard to making sure the database cumulative update is installed. It doesn't make any other mention of configuring it to use a external database. I was hoping that the configuration wizard would then prompt about which database to use but annoyingly it just set-up the configuration database locally.
How do I go about installing SharePoint on a dev environment with an external database, and will I need to reformat this machine and do it all again?
Well, this depends on what your environment looks like. For instance, is this machine part of a domain?
If so, it should be as simple as selecting "Server Farm Install", or something like that when you did the binaries installation. Then, when you run Products and Configuration Wizard, it will ask you for DB info. Note: if you are doing this, I would recommend you to be part of the 'sa' role on the database server as you will be creating databases.
If you are not part of a domain, it gets a little trickier, but not too bad. Check out this article.
http://sharepoint.microsoft.com/blogs/fromthefield/Lists/Posts/Post.aspx?ID=112
-= Plan B =-
You can always give this a whirl. This is the method we use to keep the DB guys from screaming. It also allows us to give our databases nice names.
http://technet.microsoft.com/en-us/library/cc262869.aspx
What would you say if a developer wanted to implement a sql2008 dev environment, but we were still forced to use a sql2000 test and sql2000 production environment?
Would there be anything wrong with using sql2008 on a dev server? Of course you'd need to know what functionality you couldn't use, so you didn't have problems migrating your work from the sql2008 servers to sql2000.
I'd strongly avoid developing on a different local version than the dev/qa/prod environments. Most of the time nothing will happen, but when it does it can take forever to track down the issue. Not only that, you may never be able to replicate it locally since you have a different environment.
Using Basic SQL features - you'll do OK.
I have no idea why you use this environment, but it is best to use as similar environment and DEV, QA and Production as possible, to avoid surprise when going on production.
I think that SQL 2000 uses OLEDB and SQL 2008 you can use ADO.NET provider, And there might be many more differences that you might bump into. so the best advise it NOT TO DO SO.
I don't see why you'd have a development environment using a newer version of SQL server if your staging and production environments aren't.
No matter what software will act different based on version, and there could be a bug that could come up by not keeping the same versions. I'd recommend using the same versions across your entire environment.
How about setting up a Virtual Machine (eg. under Virtual Server 2005 R2 SP1 w/Update) that has the SQL Server 2008 environment on it? This would ensure that you don't contaminate your SQL 2000 environments with it, while at the same time allowing you to try things out. You can either set this up as a VM on a separate machine, or simply add it as a VM on you own development machine.
I think best practice would be to keep all of your environments the same. I can see it being userful to try out new functionality on the new environment to determine if it would be benefical updating your test and live systems.
What is there to gain by using 2008 over 2000 if you know you have get it to work in 2000?
There are so many issues with doing this:
Performance could be totally different even with the exact same SQL
DTS packages are handled totally different
You could unknowingly use code that is incompatible with SQL2000. You would not know until you moved it to test or live and by this point you could have done a lot of wasted development around incompatible code.
etc etc etc...
There is absolutely no reason to use a different version for dev than your LIVE environment. It will just end up causing you grief and inconsistencies.