I need to use visual studio services (on cloud) to automate integration and release process.
I have 3 environments dev, test and deployment. I am planning to use only one branch the Dev that promotes the changes to next Env (TEST) and then to release.
Question 1:
Can I do it using one branch (Main Dev) or i need to create separate branch for each one? and how?
As far as i know that when using TFS server on premise, we should install release manager on the same machine and deployment agents on the different environments.
Question 2:
How can I automate release management using visual studio cloud services, taking into consideration that test and production environment don't use Azure services, they just use IIS to host our websites.
For the first question, the answer is YES and usually there should be only one branch for one release. The release/build that been deployed to the three environments in the release should be the same. Use the build from different branches in three environments does not make sense.
For the second question, you can use web deploy or Adding FTP Publishing to a Web Site in IIS 7 and then deploy via FTP.
You start using Release Management by creating a release definition in the RELEASE hub of your team project. A release definition specifies What to deploy - the set of artifacts that constitutes a new release, and How to deploy - the series of automation tasks that should be run in each environment. Each environment is simply a named logical entity that represents a deployment target for your release.
It seems you want to change project between environment in one release definition, which is not supported. A typical use case for Release Management:
You can get more information of Release Management at website https://msdn.microsoft.com/en-us/library/vs/alm/release/overview
Related
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 using Visual Studio Team Services, Release management and Continuous integration on the cloud. My release definition contains two environments: Dev and PRO.
I want to know what the possible configuration if i don't want to buy a license.
we need to associate each of the environments with specific agent. I guess they are called private agents.
So are the agents installed on those release environments (which are on local domain) private agents? if yes, can i configure those 2 environments to run under same agents and how?
What is the possible configuration where i can create 2 environments, each one corresponds to a different physical machine without paying for additional agents?
You only need to have a single Agent per network that you are deploying to (unless you want to deploy in parallel).
The Agent is an orchestrator and does not need to be installed on the target environments. You use remote PowerShell (or other scripting) to execute tasks on the target servers for deployment.
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.
we uses on-premise tfs 2008 for source safe and build engine. The build script is heavily customized with msbuild scripts. Developers uses active directory to authenticate then queue a build.
We look around to go to Visual Studio Online, question
- the big concern is the build script, we don't really want to rewrite it, is it possible to use the current MSBuild project in the VSO build process?
- for authentication, how to integrate with the on-premise AD with the VSO? how to migrate the existing security project settings to the VSO?
Ok, so the answers to all of your questions is maybe 😊.
You can continue to use your on-premises build server with VSO. If you upgrade your agents to TF Build 2010 or 2013 servers you can plug them into VSO and build in the same way.
You may be able to use the cloud build agents if you don't need custom things installed on the build agents to compile. Probably best to stick with local agents for now.
For AD you can configure an Azure Active Directory (AAD) and wire it up to VSO. There is then a connector to sync your local AD with AAD (very easy) and enable single signe-on. There are fiddly bits but mostly strait forward.
http://nakedalm.com/use-corporate-identities-existing-vso-accounts/
I enabled it for my account but without the local AD sync as I don't have one.
I have a few customer that are on VSO and sync their local AD with AAD and are very happy.
Can someone recommend a good approach for setting up a CI environment that would deploy to a multiple websites (QA/PROD) hosted on Amazon's EC2 while using TFS?
Here are the requirements I'm looking to fulfill:
Have TFS deployed somewhere to track tasks, manage source control, run tests on code check-in and do automatic deployments to a QA environment.
If everything passes the CI build in TFS, code should be automatically deployed to a QA environment hosted in Amazon EC2.
After testing, take the same deployment package we used for the QA environment and push it to an identical environment in EC2 which is our production environment.
We are a start-up so we don't need all the of bells and whistles just yet. We have limited resources currently so I am trying to be as minimal as possible while meeting the above requirements.
My first pass at this was to use the free program at Amazon for first-time users to have access to the EC2 cloud for free for 12 months. Then to setup a virtual machine at a low cost (~$20) with a web host to host our TFS environment which would then push to the Amazon cloud.
We also considered using "Visual Studio Online" to do this but it looks like it only deploys to Azure which is a little more than twice the cost to host a website with SQL on than Amazon so we don't want to go that route.
Is this a good approach? I'd appreciate any feedback. Thanks!
Using the latest TFS vNext build system this should be possible. You would need to install the AWS command line tools via npm, load your credentials, and then use aws command line to deploy to ec2.
Here is a screen shot of adding an npm task. Install the aws command line sdk. Run commands to package and upload your project.
You should install Release Management for Visual Studio 2013. It is easy to install and comes with your MSDN.
http://nakedalm.com/install-release-management-2013/
With it you can create a release pipeline with rollback to deploy your application. You will likely need to add any command line tools that you need to deploy to amazon and it will make sure they get to where they need to be.
http://nakedalm.com/building-release-pipeline-release-management-visual-studio-2013/