I'm trying to setup continuous deployment via the Aure Portal.
When doing this via the VSTS account (let's call it "VSTS Account A") which is owned by the same account owner as Azure, everything works fine.
In this case I'm trying to configure continuous deploymenet from source code held in another VSTS account (let's go with Account B).
The Azure account owner is not the Account B owner but is an admin (member of Organization Administrators) for Account B. The owner is also listed explicitly as a member of at least one project within Account B.
The problem is that when it commes to configuring "Deployment source" within the app service section, Account B is not listed as an option to choose from.
I've followed various links (e.g. part 4 of this page) about linking the VSTS account with an Azure account but still no joy. There are a couple of problems here:
The Azure classic portal has a New button within the Visual Studio Team Services section but when I choose Link To Existing, I get the following message:
Make sure you’re the account owner. If you are, maybe your account is
linked to another Azure subscription or connected to another Azure
Active Directory
Account B is not linked to another Azure Subscription or Azure AD.
The new portal doesn't even have an option to attempt to link a different account, plus the menu link says "Team Services Account Preview" so whether the Preview status has something to do with it, I don't know.
I'd have thought this would be a relatively common use case, has anyone had any joy setting up something similar?
I was finally able to choose the relevant account by making the VSTS principal a co-admin in the Azure account which contains the web app, signing in as that user and changing the directory to use from the the user dropdown menu (top-right). Note, the user account in question is already an administrator for a different Azure account, just to complicate matters further. I only had the option to change the directory once the user was a member of multiple directories.
So I finally got it configured and committing code to the specified branch was triggering a deploy. However, it transpires that setting up continuous deployment from within Azure gives you limited scope and I got constant errors which were not straightforward to fix.
I ended up getting it working properly by following these instructions:
Build: https://www.visualstudio.com/en-us/docs/build/apps/aspnet/ci/build-aspnet-4
Deploy: https://www.visualstudio.com/en-us/docs/build/apps/cd/deploy-webdeploy-webapps
Configuring it all from within VSO gives you a lot more clarity about what's actually happening.
When doing the initial setup, I had to go through an authentication step with the Azure account I was trying to deploy to and that process launches a pop-up window which was getting blocked so I missed it at first.
The initial build and deploy were fine but I was getting a build error when being triggered from a code commmit. This is because the Build Definition --> Variables --> BuildConfiguration value was set back to Release even though I set it to the correct value for my project when doing the initial configuration. Once I updated that, the next commit triggered the build which in turn created the artifact which in turn triggered the deploy which went through fine.
Googler from the future here, I had the same problem and came across a really good article called "DevOps: Connecting VSTS to Azure by Ken Muse" enter link description here
This worked like a charm for me from the first try!
Related
I am working on a course and the project had me create an account in IBM Cloud (all are in the Lite/Free account), then create an instance of IBM Watson Studio, then try to create a new, empty project. When I created the project and added the storage, I was taken back to Watson but there was no instance of a project.
I tried to create another one, but now it says that I already have an instance of the Cloud Object Storage and can't create a new one (Message says: Create Service, You can only have one instance of a Lite plan per service. To create a new instance, either delete your existing Lite plan instance or select a paid plan.). However, there is no instance listed for the COS in the Resource List (though it shows the Watson instance), and I don't get an option to select an existing COS, only to add a new one.
I have searched the help in IBM, Googled for help, logged out and back in, closed the tabs, cleared my cache, checked other answers in Stack Overflow, and can find no help to create a project, access, delete, or do anything with the instance of the COS. I tried entering the administrator and manager settings in the account for Watson Studio and COS, but that didn't help either.
Is there any way that I can correct this so I can move on in the project? I tried to add screen shots, but I'm not allowed to. Thanks for any help!
You should be able to see your COS instances at https://cloud.ibm.com/resources under the "Storage" section.
All your Watson instances will under "Services"
Another check you'll need to make is the Account. At the top right corner, make sure you're working in the same account that you initially created the Object Storage instance.
I finally figured it out! In Watson Studio in the menu, click on Administration, then click Storage Delegation. Then click the buttons to enable projects and catalogs. Try to create your project and it should automatically have your object storage available.
I have the sam issue and that work for me is that click the "Refresh" button under the 1. Storage
Like this image here
We have enabled a CI/CD pipeline using azure pipeline. Whenever someone check in to the master, the build should happen and deployment should follow. I wanted to understand how can I disallow someone to deploy to azure function web app from local visual studio
You could use RBAC Rules which may require a lot of config work.
Once you have CI/CD pipeline enabled, setting up RBAC(Role Based Access Control) helps to prevent users from getting the publishing profile, setting deployment credentials etc.,
There will definitely be some config work involved in doing this because you would have to only allow permission to one user so that user could set up the service principal connection between azure and DevOps but also prevent users from creating a deployment user.
I inherited a Heroku account. We moved to a team setup and I'm getting started with review apps.
When trying to create a review app, Heroku complains:
Cannot create this review app • Your role collab on the team xxxxx is
not allowed to perform that action.
However, I'm an admin on Heroku.
Another admin tried also and had the same problem.
The deploys prior to moving to a team, seems to have been initiated by another user, who is a collaborator, but I know for certain that the user did not actually trigger the deploy, the activity shows as being initiated by this user however it was triggered by the owner of the (then) personal app clicking create review app.
I'm trying to understand how the deploy activity is linked to the github account, so my first question is:
Is the deploy activity associated with a specific Github user? If so, where/how is the user defined?
I get the impression I need to disconnect the Github account from the pipeline, and re-connect with one of the admin's accounts, but I'm wary of disconnecting without understanding the consequences: the Heroku help on that is not clear at all.
My second question is:
What happens when I disconnect the Github account from the pipeline? Should I worry that it will mess up my running dynos? If not in disconnecting, could it cause trouble on re-connection?
Thanks
The only way I found to do this was to un-link the github capability in Heroku, and re-link with the account I wanted to use.
I had to do this recently. I had set up a pipeline in Heroku with review apps using an old Heroku account. I later wanted to remove that old account's access to the Heroku apps and I ran into the same issue you did.
Here's what I did.
I unlinked github from the pipeline. This deleted all existing review apps. But it left the staging and production apps alone and in their stages in the pipeline.
Then I re-linked github to the pipeline using the more permanent Heroku account.
And I had to re-set up the review apps configuration in the pipeline.
At that point, I had to recreate all review apps that existed before I started.
My team uses Web Deploy in order to deploy updates to our website on to our production server. The last few days I've been doing some housekeeping and have changed my password (which I made sure to update in my Web Deploy configuration) and moved the solution for our website to a different location in TFS. I'm not sure which (if either) of these has caused the issue, but I am now no longer able to publish our website using Web Deploy.
I can preview the publish fine, but I can't actually publish it.
The Output in Visual Studio shows this:
Start Web Deploy Publish the Application/package to https://[REDACTED]:8172/msdeploy.axd?site=[REDACTED] ...
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets(4270,5): Error ERROR_COULD_NOT_CONNECT_TO_REMOTESVC: Web deployment task failed. (Could not connect to the remote computer ("[REDACTED]") using the specified process ("Web Management Service") because the server did not respond. Make sure that the process ("Web Management Service") is started on the remote computer. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_COULD_NOT_CONNECT_TO_REMOTESVC.)
Publish failed to deploy.
(Note that I've removed some identifying information from this log, which has been replaced with '[REDACTED]')
I found a page describing this issue here: http://www.iis.net/learn/publish/troubleshooting-web-deploy/troubleshooting-web-deploy-problems-with-visual-studio
It says to check in the WMSvc log to find the status and substatus codes for further troubleshooting.
Here I've colour coded lines relating to the preview in green and lines relating to the actual publish in red. As you can see, the requests returned with a 200 (OK) status, meaning the server is not aware of any error occuring. However Visual Studio reports a failure and my production website has not been updated.
The fact that log entries are generated tells me that Web Deploy is properly installed and the handler is setup correctly.
It seems the deploy always fails after ~30 seconds. This could be coincidence, but I'm wondering if there's a timeout at play.
Could anyone suggest further troubleshooting steps?
EDIT: This issue occurs when I try to publish to ANY server, so it's definitely a client issue and not a server issue.
EDIT2: I have two branches of my project, Main and Dev. I just discovered that I can still publish from Dev, just not from Main. They both have identical settings. Very weird.
This can be caused by few reasons. I've written this blogpost earlier about the issues.
When we install the Web Deploy tool, it creates local users "WDeployConfigWriter" and "WDeployAdmin". In your case, you've explicitly changed the password to reset these local users passwords I think, or, the passwords of those in charge. To reset these local users passwords, you can do following:
"Control Panel -> User Accounts -> Give other users access to this
computer -> Advanced -> Advanced -> Users"
Reset WDeployConfigWriter's password
Reset WDeployAdmin's password
"IIS -> Server Node -> Management Service Delegation"
Right click on each
rule with users "WDeployAdmin" and "WDeployConfigWriter"
Click Edit
Click on "Set..." button in "Run As" group
Enter the name of the account you are going to update the password of
Enter password on two areas
If the operation is still erroneous see Event Logs on Windows, they are the real deals here. Check this link.
We are looking to create a test TFS 2010 server based on our live instance.
One method which has been suggested is to clone the Team Project Collection (TPC) onto to another server - as detailed in this existing answer but I think there are a few additional steps?
In order to get the cloned TPC's GUID reset, I take it we would have to first reattach the cloned TPC in the admin console on the original server then detach, move and reattach on to test Server/TFS instance.
We are not running Sharepoint/WSS but would there be additional config work required on the test server with SSRS - in order for new projects to be created against the cloned TPC?
Are there additional using diffrent AD accounts for services or can all of that be resolved within the admin console on the new server?
Both servers will running on VMWare and on the same domain but different AD accounts would be used on the two servers to help prevent any unwanted interactions between the TFS instances.
I will recommended convert your TFS to virtual environment P2V using SCVMM, see this article,
http://mohamedradwan.wordpress.com/2011/06/23/converting-my-physical-domain-controller-to-a-virtual-machine-p2v/