My team uses TeamCity for continuous integration. It will build, test and deploy web applications via Web Deploy to dev and qa web servers. The tricky part is deploying to a production web server - our policy dictates that developers cannot deploy to production, only a system administrator can.
Our current approach is to have TeamCity build a web deployment package, which the administrator can download and install on the production web server. However, we'd like to allow them to simply click "Run" on a build configuration, but we're not sure how to secure that button.
We could create a TeamCity project that only administrators have access to, but we also have to address Web Deploy security. The Web Deploy service needs to be authenticated with a local admin account on the production server. We don't want developers having access to the username/password in a build script, nor do we want every build agent running as this account since developers could create a build that uses it to deploy to production.
I've haven't had much luck finding resources on TeamCity security/deployment best practices, but I can't imagine we're the only company in this situation. How do others manage automated deployment security?
First of all auto deployment on live server is not a good idea. Deployments should be automated till staging. If you still want to do it, ez, short and secure way is to use Ant script. Write a short script to use SSH or sftp and deployment is done. You can create two profiles for your project and add an extra step in "Build steps" for Pro deployment by admin.
Related
what I did;
I have my c# windows form application on Azure Repo and I created a build.
I assigned my physical test server to Azure DevOps under the Deployment groups page. And it is online.
I defined a release, I added an artifact that refers to the build pipeline from the Azure repo.
Now I want to transfer my windows form app release files to my physical test server (windows) under the Desktop folder and run. (also stop and delete previous app if it is already running)
For that, I tried to add a stage. But for the stage templates, I don't know which one to choose. There are deployment options for IIS and Azure services.
Bufre, I published my ASP.NET app using IIS website deployment. Worked fine. But how to do it for a desktop application? How to transfer and run?
I see a as a similar issue here, But I am new to YAML files and I could not produce.
Where to mention target physical path, which template to choose? Could you please advise on the steps?
You must install the DevOps agent on this server, then add it to the agent pool and then use any task that allows to install your app (depends on what kind of app you have). All tasks will be executed on the server directly, so you can use PowerShell, cmd or what ever.
https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/v2-windows?view=azure-devops
https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/pools-queues?view=azure-devops&tabs=yaml%2Cbrowser
I am developing CD release pipeline using TFS 2015 update 2 on-prem instance. I'm relying on ARM template to setup Azure website and Azure Sql server. I'm using FTP method for deploying website bits from internal Build server to Azure website. For this website deployment I'm reading the credentials from PublsihingProfile of the newly created website.
Is this a right way or can you suggest a better way? Any comments are appreciated.
P.S. Customer wants to use FTP method and not WebDeploy.
If you really have to use FTP, and the thing you're not happy with is the process/password secret management, you could try this:
https://marketplace.visualstudio.com/items?itemName=januskamphansen.ftpupload-task
Its a VSTS extension task for release, which works with the vnext build/release system in VSTS or TFS2015 server. This task lets you put the parameters in against each environment you setup, and mark the passwords as secrets so they wont come out in logs or the UI.
The step basically wraps up the process of doing the ftp bit for you - you may want to do other steps as part of the release.
We currently have this architecture :
production servers with limited access
Subversion server where developpers can commit
Teamcity server that build the websites from SVN and deploy it to the production server
The purpose is to make it impossible to deploy a website without commiting the code to the appropriate branch. And it's working very well.
Now we're moving some stuff to azure. And I don't want to put my publish profile in the project because if I do so any one can publish from his visual studio instance.
I thought about this : create publish profiles from the azure account, upload them to the CI server and passe an absolute path to the publishprofile msbuild parameter.
Do you think there is a cleaner way to do this : I'd prefer to do the profile uploading directly in teamcity.
I'm working with Atlassian Bamboo on Demand for Continuous Integration and it works great.
Now I'm trying to use the "Deploy" feature and the problem is that I'm working with Azure (ftp, publish, git, mercurial... I really don't care how) and I can't find a "task" which could perform it.
Has anyone achieved this?
I do automated deployments to AWS from bamboo, but the concept is pretty much the same.
Bamboo has no specific options for deploying to the public cloud, so you have to build or call an existing deployment tool. At the end of the day bamboo deployments provide you with meta-data over which build has been deployed to which environment, and security over who can do deploys, but its up to you have to make the actual deploy work. Bamboo does give you a totally extensible engine for controlling the "how" via scripting. The deployment engine is basically a cut down version of the CI engine with a subset of tasks.
I resolved to build our deployment tooling due to it being fairly simple to get started and a worthwhile investment in time because this will be used often and improved over time. Bamboo gives me authorization and access control, and my scripts give me fine grained control of my deployments.
I'm assuming you are running a bamboo agent on a windows image like me. So powershell scripts are your friend . If you're running in linux you'll want to do the same with bash.
I have a powershell scripts controlling my deployments through a controller/agent model.
The controller script is source controlled and maintained in mercurial repo. This is pulled by the repository task.
The agent is a powershell script wrapped by a simple webapi rest service with a custom authentication mechanism. The agent is setup when an app server instance is provisioned in ec2. We use puppet for server provisioning.
The controller does the following for a deployment
connects to the vpc
determines the available nodes in my web farm using ec2
selects the first node and sends the node an "upgrade database" command
then proceeds to send "upgrade app server" command to each node
The logic for doing the deploy is parameterized so it can be re-used for deployment to different environment. I use bamboo deploy variables to manage feeding parameters for the different environments.
DEV is deployed automatically, test, staging and prod are all manual click deploys which are locked down to specific users.
One option I considered but did not invest the time to look at as aws elastic beanstalk as a deployment tool. It has a rich api for deploys. On the Azure side it looks like web deploy supports deployment to Azure IIS sites.
I would like use a continuous integration system in my projects. However, I don't want to use a server sitting in my office, instead I'd like my continuous integration server to run on Windows Azure. Has anyone set this up? Are there recipes to host Hudson or CruiseControl.Net (or any other CI system) within Azure?
We use the Build Manager in Team Foundation Server to push our automated builds to Azure. We set up our Azure hosted services to allow for Web Publish through remote desktop using this plugin - http://dunnry.com/blog/2010/12/20/UsingWebDeployWithWindowsAzure.aspx
You do not need to involve Team Foundation Server to use the plugin - you can set up your instances to publish to azure instantaneously through Visual Studio Web Publish without CI.
I think there are two parts to the Azure CI solution - automated builds from your source control and actually pushing the bits to azure. The plugin makes the publish to Azure much, much faster. So if you want real time access to changes on Azure, you will need to look into the plugin.
It sounds like you are trying to use Azure as an infrastructure provider, which runs a VM where your builds happen.
This is not a particularly good use-case for Azure. Azure is a platform to run your custom-built applications. While it does provide VM's similarly to Amazon or other IaaS cloud providers, those VM's are "stateless", can go up and down at will and meant to act as application servers where more than one can be up at any given time.
You can probably get this to work on an Azure VM but I am not sure if the pain would be worth it.
Azure's instances are application servers, not "windows servers".
HTH
I have installed Jenkins on Windows Azure, it works very well for me.
http://blogs.msdn.com/b/gongcheng/archive/2013/02/27/jenkins-on-windows-azure-the-missing-manual.aspx