I'd like to run some integration tests in Azure. I can't run these in TFServices because they require a database. I'm wondering if it would be possible to push my project up to TFS, have TFS build the solution and push it to Azure, and then have Azure run some tests against a test database before committing it to production. Any failures along the pipeline populate back to visual studio. Is this even remotely possible?
if it would be possible to push my project up to TFS, have TFS build
the solution and push it to Azure
Yes, this is possible.
and then have Azure run some tests against a test database before
committing it to production
Well, this is not possible.
Any failures along the pipeline populate back to visual studio
And this is in a dream world. The only viable resolution is to have work items created out from test fails. But populate back to Visual Studio is a dream.
Going back to have Azure run some tests against a test database before committing to production.
What exactly is the issue you face when you want to run integration tests from TF Services? is this just an SQL Azure Firewall issue or something else? Have you even tried it? What was the result? If it is just a Firewall issue you most probably can mitigate by using some custom code in test initialization phase - like disabling firewall for the SQL Azure server, then enabling it again on test tear down phase.
Related
Has anyone managed so set up a working deploy pipeline using Visual Studio Team Services RELEASE tasks? All the info I can find seem to be based on the Nuget publishing package which takes its parameters directly from the source. I am trying to get this working in the proper release workflow with multiple environments, dev to QA to prod pipeline etc.
The tooling does not seem to be in place for that scenario - or at least, I cannot figure out any combination of parameter where the powershell publish task in VSTS actually populates the app_data folder and sets up the schedule.
Frankly I am completely stumped.
You can use "Azure Web App Deployment" task to deploy your WebJobs and use CRON expression to set up the schedule.
A similar questions for your reference: How to deploy a webjob through CI in VSO with vNext
I'm working on a check in policy and while testing it the first time, I got an email from a teammate saying he couldn't commit any files, because when I installed the policy for testing on my machine, his TFS died, because he didn't have the policy DLL installed and registered. It seems that when I registered the policy locally, the TFS server registered it for the whole team, and the other members don't have it yet, so their commits blew up.
But how are you supposed to develop and test a policy if the only way to do this is installing in the global TFS server for everyone? Clearly, the policy code isn't ready for deployment before you ever try to test it, and you can't test it if testing breaks TFS for everyone until you test and deploy it.
What is the way out of this problem? Ideally, I'd like to have a local-only policy, but that doesn't seem to be possible.
Policies are set on a per Team Project basis. There is no local setting for check in policies, they are created against the Team Project and everyone who is using that Team Project will be affected, meaning that you will have to roll out the dll to all users.
Your best solution is to have a test Team Project where you can try out new builds / check-in policies and other bits and pieces in isolation.
Once you are happy with what you have, you can then apply the same items to the main Team Project that your team is working on.
Been working some with SharePoint 2010 for a litle while and it feels like my deployment method is way to slow and way to complicated, so my question is basically..
Is there anyway for me to deploy a package to a remote sharepoint server directly from Visual studio?..
For instance.. could I some how create a connection between my visual studio project and the sharepoint server I want to deploy to and then simply press some kind of "Deploy-button" that then deploys the whole project(or even better just my changes) against the remote sharepoint-server?
Thanks in advance!
This won't be easy. Firstly there is the Deploy option which you have for every SharePoint project. This deploys the Solution (WSP) to the URL you specified under Site URL for the project. However this won't help you in your case because it only deploys to a local SharePoint Server.
There simply is no automated way to deploy to a remote server from within Visual Studio. What you are talking about actually has aspects of Continuous Integration -> Continuously wanting to deploy on each check-in.
The perfect tool for continuous integration is the Team Foundation Server. There you will have the possibility to create a deployment script (via a TFS workflow) which automatically increases the version number of your assemblies as well as deploys them to a remote SharePoint server. This usually is done via PowerShell remoting.
PowerShell is the keyword here as in the end you could create your own PowerShell deploy scripts and just call them in the Visual Studio Post-Build instead of using a full fledged TFS.
I've just read the VS 2010 Database Project Guidance document (link to guidance document) and I'm still none the wiser about what's a sensible strategy for Continuous Integration DB builds and Unit Testing the DB.
We currently have our DB project in the same solution as our application and build the whole solution on check-in, is deploying the DB with every build practical?
Should we separate the DB projects to another solution and then they'd get built less often so deploying on build would be more sensible?
Should we forget about automatically deploying all together and just make that a manual step?
How do you deploy databases for Database Unit Test projects?
There's a lot of information in the guidance document but no definitive answers.
Thanks
Ben
It depends what your goals are. What environment(s) are you considering deploying to on every build?
How often, and where, you deploy to is usually determined by your QA and/or release processes. I'm assuming you don't want to auto-deploy to the production database on every check-in, chances are you have a QA process that needs to happen first.
So I'd be looking at what environments do you have, what are they used for, and how often would you like them to be updated. It is pretty common to have a QA environment that is updated nightly, but updating it on every checkin would disrupt QA activities.
Some people have an environment that is deployed to on every build and automated tests are run against it, if you have this then deploying there every build would make sense.
You can build DB projects without having to deploy them, the build and deploy are separate concepts when it comes to DB projects in Visual Studio.
We are beginning to use Visual Studio Database Edition 2010 (VSTSDB) for our continuous integration. In short I have our nightly build creating the Deploy SQL and then running the script on a SQL Server. I will eventually have integration unit tests run on the newly created database(s) after the build is dropped and database is created.
I am wondering about the best practice of where to keep the testing SQL Server for the build. This would either be the same box as the TFS Build Agent, or on another system.
Any help is appreciated.
The ideal place would be the SQL Server instance where you already host test databases.
I would try to avoid placing it on the TFS build agent machine.