I'm using Jenkins to produce cspkg files using msbuild. It stores build results in azure blob storage. Then I use management portal to deploy them.
The biggest drawbacks I see are:
1. Deployments can be accidentally deleted easily.
2. There is no straightforward* way to check which version the cloud service has.
Is there a better way to manage deployments?
Its definitely not the best experience is it?
The approach I tend to use is as follows:
Build the deployment package and add the version number to the package filename (taken from AssemblyInfo.cs) e.g. MyCloudService-1.2.0.0.cspkg - this should be trivial using msbuild.
Push the package to Cloud Storage.
Perform the deployment of the package from Storage, with the Deployment Label '[CLOUD SERVICE NAME]-[VERSION] # [DATE & TIME]' e.g. 'MyCloudService-1.2.0.0 # 10-09-2015 16:30'
Check the deployment package into a 'Packages' directory in source control.
If you need to identify the version of the package deployed to the cloud service, you can see the Deployment Label on the Azure Management Portal:
'Old' Portal (manage.windowsazure.com):
'New' Portal (portal.azure.com):
Related
I am using Cloud Run Continuous Deployment to watch a github repo & build the project upon a push to the production branch. Instead of specifying a Dockerfile, I am letting Google Cloud Buildpacks do all the work, since my codebase is written in Node.js.
I haven't yet been able to run a functional deployment due to the service account running into some permissions errors, but once I get past those, I am wondering how I would be able to initialize the firebase admin SDK inside the build. In my dev code, I have a service account JSON file and initialize the admin SDK using that file, but I don't know if this possible in the cloud build. If I can't upload private files to the cloud build, am I able to use the service account that creates the build to initialize the admin sdk? Is there another way to initialize the admin app in the build, such as using env variables? For reference, I am only using the admin sdk to read and write to our firestore database.
We currently use TeamCity to build a deployment artifact, then a further TeamCity task takes that artifact and deploys it to our development and testing servers on demand.
We can store the passwords and other secret data in properties files that we can check into source control, as these are all internal servers and the developers have full access to them.
However for release to Production (and our final test layer) there are secret passwords and configuration that we don't want checked into the normal source control, or to have development be able to discover the passwords. So to do 'real' deployments we have to hand the artifact over to another team and they maintain a properties file with the production values.
What methods exist to store these secrets and allow TeamCity to run a deploy without ever leaking the secrets out?
(note I am one of the devs and it is not a trust issue... I don't want to have the ability to find out prod passwords so I can never accidently know them and do some horrific damage!)
Probably what you need here, is to create a separate project with narrower scope of permissions (for example, allow only certain people to edit build configurations). In this project create a build configuration, responsible for deployment. In this configuration, you can define a Typed Parameter of type 'password' to store the password to the production environment.
Another option is to use Deployer Plugin, especially its ability to deploy over ssh with private key authentication
If you are OK to use a third party solution, consider using a solution like CloudMunch which can help you to perform release management functions with these secure parameters collected at deploy time and encrypted post deployment.
Disclaimer: I work with CloudMunch
You can do 2 things.
Use a teamcity project to deploy artefacts for production only. This will only be accessible to ops members.
Teamcity also supports running agents with different user ids. You can create a new user id which can have access to the production "secrets" (passwords and configuration). Use this id to run the targets in the 1st step.
We've been experimenting with Octopus Deploy on a development PC and now want to transfer the environment we've created onto our main Octopus Deploy server (which is used by other teams and already has a few environment set up on it).
So we would like to backup/restore this one environment. However, it looks like Octopus only allows you to backup/restore the entire database.
Is it possible to move a single environment from one Octopus server to another using backup/restore or another means?
What worked for me was simply doing the following in order:
Shutting down Octopus service so that no transaction going through.
Copy the raven database (usually stored in Program Files\Data) to your new server.
Install the new Octopus server and during the setup, in the Storage Tab, specify the location of your data location copied in the second step above.
The Octopus developer, Paul, mentions the great thing about RavenDB is the installation. It requires no services running like SQL. It's just a copy paste of the data itself and great for installation and portability.
There's currently no way to backup/restore just part of the database - you'd need to restore a full backup, and then delete the information you don't need.
Octopus 2.0 (which is now a public beta) has a comprehensive REST API so it would be possible to use that API to fetch a subset of information and import it to your new Octopus server.
How best should I accomplish the following deployment objectives with Git deployment for Azure?
Easily switch when working locally to either use fake in-memory data or (eventually) non-production snapshot of real data
Deploy to staging environment on Azure such that at first I could use fake in-memory data and eventually move to non-production snapshot of real data.
Deploy to production with real data
I currently deploy using Github and a staging branch to a staging Azure website. Since I deploy to a public repo, the web.config file is ignored by git. (EDIT: I just learned that ignoring web.config actually causes deployment error on azure)
Any help/suggestion is appreciated.
It's actually supposed to be simpler than that. Please see this page. Basically, the idea is that you set some AppSettings in the Azure portal to override the default values that are committed to your repo.
Well... Here's what I did that works for me right now.
To quickly switch between fake in-memory data locally, I use a compilation symbol LOCAL and a preprocessor directive #if LOCAL.
Same compilation symbol works when you deploy to Azure, so I can work on fake data until I'm ready to switch to real db. I can also use the app settings if I really want to make to switch it more easily.
The challenge was to keep a web.config with "secrets" (like connection string) locally and not expose it to Github. I added it to .gitignore, but then my deployments started failing on Azure because it could not find the web.config. Just copying it to wwwroot via ftp did not help - Azure was looking for web.config in the repository.
So, to make this work I "slightly" altered the deployment process by first copying the Web.config from wwwroot to the repository before running the default deploy.cmd. This was simple - this is what you do:
Create a .deployment file in the root of your repository with the following:
[config]
command = deploy.my.cmd
Create deploy.my.cmd with the following script:
xcopy %DEPLOYMENT_TARGET%\Web.config %DEPLOYMENT_SOURCE%\\ /Y
deploy.cmd
Now, I have web.config with secrets locally. Git ignores this file. I uploaded the correct web.config to Azure via FTP, and it gets used whenever I deploy.
I am new windows azure user. I have gotten selected for 90 days trial account and I am able to upload my ASP.NET MVC3 application to my account. My site is also running now. After I did publish my site, I added more model, views and controller to my proramme. Now I can not find a way to update my application. I can again publish my application but update option is not there. I want to update my new code only but the package option is creating full application. How I can update the new code to my site in windows azure cloud?
[Changed spelling]
With Windows Azure you can publish/update an application following ways:
Log into you Windows Azure account. Select you hosted server name and at the top panel you will see "Upgrade" option, when you will use this option you will be given a chance to select your CSPKG and CSCFG file from local file system or from Windows Azure storage. Once you selected new or updated CSPKG, your current running service will bee upgraded.
You can also use Windows Azure PowerShell Cmdlets to upgrade your current running hosted service using "Update-Deployment" command:
2.1 http://wappowershell.codeplex.com/
You can other 3rd party applications created using Windows Azure Service Management API to upgrade/manage your current running hosted service.
3.1 http://wapmmc.codeplex.com/
3.2 http://www.cerebrata.com/Products/CloudStorageStudio/Default.aspx
Note: With Visual Studio if you again publish your application, it will delete the current running hosted service and then create the new on so for update it is not the good one.
Finally based on your question about partial update, that is not supported. Even when you make a single line change in your code the deployment will be considered a full deployment even when the action is "update/upgrade". There is no diff package deployment so evertime you update your Windows Azure application, you will use the newly created CSPKG file and upgrade your hosted application.
Regarding partial update: If you have multiple Roles, you may choose to upgrade a single role (so that would be a partial update of the deployment). For a given Role, all code is redeployed. If you're running more than one instance, the update will be rolled out across groups of instances, not all instances at once.
For updates such as static content: if you move these into blob storage (a great place for css, jquery, images, etc.), then you may update this content by simply uploading new items to blob storage individually. These updates don't require any code to be rebuilt or redeployed.
If you're in dev mode (e.g. non-production), you may enable Web Deploy, which then allows very fast updates of your app to the running instance. This only works in single-instance mode, and it's great when doing frequent code+test cycles.