I am looking to run some automated RestSharp API tests in Continuous integration.
Right now, the application API is running in it's own project, which is set as a Startup Project. The Web App is running in a separate project. And when they are both run manually from Visual Studio, the app's UI can be manually tested against the locally running API (That's just for reference, I only need the API project to run for my tests to work).
So right now, to run my automated API tests as I script them, I start the API project to get the API up and running locally, then open a new window of Visual Studio, and run my MSTests from there.
My question is, how do I get the API project up and running automatically, so the tests can be run against the API? Can I start tests, while the API project is actively running in Visual Studio?
Mainly, how can I run these API tests in Continuous Integration, if the API needs to be started up in a separate VS window every time?
Sorry for the fairly broad question, I am a test automation engineer, and not an API developer. A pointer in the right direction would be great.
You can deploy the Web API to IIS (or IIS Express). In that way, it would be running in the background rather than launched from Visual Studio. The CI tool would then update the deployment after it creates a new build, but before it runs the tests. I would start with the documentation for whatever CI/CD system you are using, but assuming you're using TFS, here is a reasonable starting point: https://www.visualstudio.com/en-us/docs/build/apps/. There are links from that page for deployment and CI.
Related
I am trying to get an Azure App Service to recognize my Web Job - meaning to show it in the portal under "Web Jobs" in the App Service. And to also run it on the schedule defined with a TimerTrigger attribute.
It is a .NET Core 2.2 Console Application with multiple web job classes in it. The App Service it runs within is a separate project and web site. I am able to publish it from Visual Studio and it shows as it should under Web Jobs in the Web App. But if I delete it and try the publish from Octopus to the same place WITHOUT doing the VS 2017 publish first, it won't show up.
My issue is that in a new environment, the Web Job does not get created when I use Octopus to deploy the Web Job files as described here:
http://blog.amitapple.com/post/74215124623/deploy-azure-webjobs
by setting the physical path in my Octopus package deployment:
App_Data\jobs\continuous\myjob
This is the same path as when I publish from Visual Studio 2017.
Related to this question, but there seems to be a step missing since the files are in the right place, but the web job does not appear in the portal.
How to deploy azure webjob using Octopus
Is there some additional ssetup or registration step for the Web Job to run or should the App Service just recognize the web job is there when the files appear in the correct place? Restarting the app service does not help.
Since you have a web app along with a web job, I would follow the steps outlined at https://octopus.com/docs/deployment-examples/azure-deployments/deploying-a-package-to-an-azure-web-app/deploying-web-jobs. You can build your project using .nuspec to get your .npkg and push/upload the package to Octopus.
Hope that helps.
I have a web application which I want to test with Visual Studio Load Test feature.
I could create a load test on my local machine successfully.
My application deployed to a Windows Server and I would like to test it using TFS.
Can I deploy load test with my web application as well?
I need a stress test so I would like to use load test for hours which is quite difficult using my local machine, but unfortunately I don't find any useful tutorial.
My expectation is that I can deploy my load tests, and I can run that without local machine and Visual Studio.
I try to figure out how I can debug unit tests and integration tests in Visual Studio 2015 that be execute in a Docker container.
I've made an ASP.Net Core 1.1 app that is Dockerized and is connect to a Postgresql Database via the docker-compose.json file.
I wrote some unit and integration tests. The integration tests run tests against a database, so I've created a docker-compose.json to :
launch the database
compile code
launch tests with the command docker test test/path-to-the-test-project/project.json
I run the docker-compose by hand with powershell. Everything work well, but it's realy painfull to debug by reading thousand lines of log.
So, how can we execute the test suite in Visual Studio and debug the test code like we can debug code running in a Docker container (and use break point and other debug tools) ?
(Debuging an ASP.Net Core app in a Docker container was explained in the Microsoft documentation)
For now there isn't way to debug integrations test who are executed in a docker environment.
The way I found is to launch the Dockerized Database by hand and execute integrations tests in Visual Studio.
With that, I cant execute and debug tests. I can also execute OpenCover, and that's nice.
I have the following doubts in BizTalk deployment:
How to deploy the BizTalk application to the production server?
When I am modify the existing BizTalk application like artifacts, custom pipeline/functions, custom classes, etc., how again do I deploy the BizTalk application to the server?
I know BTDF is the one of the best tools for deploying BizTalk applications and we can deploy BizTalk application to server using it?
1. Deployment
For deployment you can use the built-in MSI generation wizard.
It means you deploy the application on a dev environment using Visual Studio, then on the admin console, export the application a MSI using the wizard.
Finally you can use that MSI to deploy the app to the Production server.
That's a two step process (Run MSI, import MSI in Bizalk Admin console).
Note that only your Biztalk assemblies are installed by the MSI.
If you use .NET assemblies in your solution, they need to be GAC'ed manually.
You will also need to restart the host instances running your Biztalk application.
See details here:
https://msdn.microsoft.com/en-ca/library/aa559168.aspx
That's a few manual steps.
Alternatively you can automate some of these steps by using the BTSTask, a command line tool included with Biztalk.
You can script all the manual steps.
Obviously it takes time to write such script, so it's only worth it if you are going to deploy many times in non-dev environments.
BTSTask reference:
https://msdn.microsoft.com/en-ca/library/aa559686.aspx
2. Redeployment
Usually you completely remove the old version and then install the new one:
Delete the application from the Biztalk Administration Console and ungac the assemblies it uses.
The whole process would look like:
1. Make sure there are no running instances in you application. You can always disable your receive location and let the running instances complete
2. Delete Biztalk application
3. UnGAC associated assemblies
4. Deploy new Biztalk application version and GAC associated assemblies
5. Restart Host Instances used by your Biztalk application
EDIT: To address OP's concern about deleting a running application:
It is indeed possible to deploy resources independently and never delete your application.
But it does not mean you will not interrupt the service.
An orchestration for example, can never be redeployed when it has running instances.
So assuming that you divided your functionality properly into applications, I find it cleaner and easier to delete the whole application than going after each resource.
Otherwise, yes you can go and replace your resources separately.
But to me it seems like an overhead caused by not having defined applications correctly.
3. BTDF
The Biztalk Deployment Framework is a good tool to have some kind of automation in your deployment without having to write the scripts yourself.
Good compromise between customization to your needs and setup time.
I have used it on a freelance project. It was very helpful because I was able to deliver a package with a only a couple of deployment instructions, and the non-techie client was able to deploy painlessly.
I am planning to move from TeamCity to Visual Studio Team Services CI builds (mainly to avoid having to run and manager a server for TeamCity, version control repository etc.)
My TeamCity build uses a third party obfuscator, called Crypto Obfuscator for obfuscating code when it is built. I have searched through all available documentation online but cannot find out if Team Services lets you somehow install and use third party tools in CI builds.
If not, is there any way obfuscation can be introduced in Team Services CI builds?
Thanks for your time.
The new build system is task-based -- you can either write a custom task and upload it to Team Services, or just call the appropriate command-line utilities on your build server.
If you're using a hosted build server, you'll have no ability to install third-party tools.
The Team Services build service (build server hosted by Microsoft) is not for you. You won't be able to run the obfuscation program you have.
But you can use your own Build server, connect it to Team Services and keep your MSBuild script.