Given:
Multiple client-server applications across hundreds of servers and thousands of clients.
TFS 2012 for source control and automated builds.
SCCM 2012 as the deployment technology.
Is System Centre Orchestrator 2012 the most appropriate tool to facilitate production ready TFS builds to be pushed to SCCM for deployment?
Why?
How?
Answer is No.
It seems that if you want a new version of an application in SCCM 2012 you can use Application Supersedence
...So in theory I could detect the drop of a new production .msi in a folder and then automate the supersedence with powershell.
Now I am thinking this is NOT a good idea for production in my environment, really this question was me thinking by writing things out. I am attracted to the idea of continuous deployment, but not to production (in my environment).
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'm asking myself if it is a common practice to have automatic updates activated on build server with windows operating system. The build server uses jenkins, visual studio and java to drive the build. On the one hand I want a system that is clearly defined which software is installed. On the other I have a server that should have up to date patches installed.
What is a common practice?
In my previous company, we were using Windows to host the Jenkins master and all the slaves. We were building our code with Visual Studio 2010. We tested the automatic updates and it broke our configuration 2 times (in 3 years). So if you want to control your server's configuration, I recommend to apply the Microsoft patches manually (you can test the patches on a staging environment before applying the patch in production).
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.
We work for a small firm and we just started getting few SharePoint Projects.
Setup what we have done:
Purchased a new server and installed SharePoint 2010, SQL 2008R2, Visual Studio 2010 in the same server.
Created the application in the SharePoint Central Administration.
Developers directly login to server built the project using Visual Studio. (In server, only 2 ppl can login and work)
Issue:
1. We started getting 2 more projects, and the count of developers became more.
We need to know how to set up an environment where all the developers can work.
Also need to know if there is any way that they can work from local and then we can push the application to the server.
We do not have budget to get one more server and install TFS, so need to know if there is any other repository where we can make the above task possible.
Any help from all you people will me greatful.
Expecting a reply at the earliest.
Regards,
Alex
Depending on what specification laptops/PC's you have you may be able to create a virtual machine to do the development within. All the licenses here would be covered by MSDN subscription(if your devs have this) I think. VM's can get very big so what all the developers did in my last company was to have an external HD with our VM's on there, i think we were using e-sata connected external hd's
If you have TFS you should be able to connect the VM's up to this which essentially would allow you to use the build functionality to create your WSP packages ready for production(once testing has passed on your VM obviously), this package can then be dropped by TFS automatically to your production server ready for installation.
The great thing about this model is that you can have multiple VM's so if you break one you can just use a fresh one! All developers will be on a different VM but with some configuration would be working from the same source code.
Essentially this method has it's drawbacks and it's positives but i found this way was really benificial to me as i was learning how to do things and regularly needed a new VM :P
Something to note about what you have said, It is not recommended that you have VS on your production server.
Hope this helps
Truez
Management wants us to start using Visual Studio through Xenapp when we are working remotely. I can't find any good documents about how teams are using this. The biggest issue seems to be managing workspaces. Most development can be done without a connection using TDD but getting the latest versions is a problem. The Xenapp version of VS doesn't recognize the workspace on the local machine. You can create a workspace to the virtual desktop but then you would need to develop in the virtual machine. If you do map the the virtual environment to the local it gets all files again. This is a problem as that alone can take up to an hour.
We have 4 Xenapp servers that are load balanced so you never know which one you will end up on. If anyone is doing this I would appreciate any help.