I have
developed a skeleton Android App in Android Studio
the Build pipeline in Azure DevOps
An Internal Testing track for this app on my Google Dev Console
Uploaded MANUALLY via the GUI of the Google Dev Console the signed .aab bundle produced
via Android Studio to the Internal Testing Track
The testers that had been set up for the track have been able to install the app on their devices and test it
The steps above work fine.
I then implemented the following
Created a Release Pipeline in Azure DevOps using the editor (not in YAML)
In this Release the Google Play Release Bundle plugin has been used (see pics
below) with its Track Property set to "Internal test" as per the available dropdown
value
Added a Deploy Stage following this Release (see pics below).
However, when the Release pipeline runs I get the error in the title (Only releases with status draft may be created on draft app.) that is also visible in the screenshots below.
I read the SO posts below
Only releases with status draft may be created on draft app
ERROR: Only releases with status draft may be created on draft app
and also articles/documentation like the following
Trigger Azure Pipelines with Postman and Parameters
Release pipelines - What is a draft Release
Releases - Create
How do I specify variables I want to edit when a release is created?
Publish to Google Play Store
I suspect that to remove the error I need to somehow create a release such that
isDraft = true;
that is a draft release that would not be rejected on deployment by the Azure Dev Console Internal Testing Track, but I am a bit at loss with it as I would have expected the Google Play Release Bundle plugin to take care of this detail for me but something apparently goes wrong or I do not clearly understand and I cannot figure out what it is or how to approach this problem in the best/simplest way.
Related
I have deployed a website containing react as front end and node as back end using azure devops in azure vm and its working perfect. now i want to display build number & release number in page footer of the website. can anyone help with it, i'm quite new to azure devops so not able to find any helping solution.
Edit:
as suggested i have added below variables to my ci pipeline as can be seen here
and in my code i have tried to add them to footer as you can see here
but the output i'm getting is here
can't get where i'm going wrong, in the code image you can see i have used one azure devops link to get build number value but i'm not sure how to get that link, i have followed this blog, can someone help on it
In the build pipeline, you can use the predefined variable Build.BuildNumber to get the build number of current build. For more details, you can see here.
And in the release pipeline, you can use the predefined variable Release.ReleaseName to get the release name (release number) of current release. For more details, you can see here.
In the pipelines, you can use the predefined variables to get the values you require and write them into the code of your web app to set the page footer.
Maybe, you can try to develop a script to write the build number and release name into the code of your web app, and call this script in the build pipeline and release pipeline.
I have an pipeline which will have few task mentioned in the image. I'm creating a bug work item when a particular task failed which is working fine using logic app.
Now my problem is I don't want to add every time new task for bug creation after each deployment task mentioned in the image.
Is there any way I can create only one bug work item based on failure in any of the task in the pipeline. may be in the last or somewhere..?
Not sure why you had to go the Logic app route as there is an option to do this with Azure Pipelines itself out of the box.
Navigate to {your pipeline} > Options as shown below:
If the build pipeline fails, you can automatically create a work item to track getting the problem fixed. You can specify the work item type. You can also select if you want to assign the work item to the requestor. For example, if this is a CI build, and a team member checks in some code that breaks the build, then the work item is assigned to that person.
Additional Fields: You can also set the value of other work item fields. For example:
Field Value
------- -------
System.Title Build $(Build.BuildNumber) failed
System.Reason Build failure
Check Build Options for more details.
UPDATE:
Doing this for Release Pipelines is not supported as an out of the box feature as of today. However, there are extensions available in the Visual Studio marketplace that can be used as alternatives until it is supported.
Here are two such extensions:
Create Bug on Release failure
Create Work Item
Another idea with PowerShell tasks is discussed here.
I have create a function app using visual studio code and then published it. Function app works fine. I am now using code deployment feature(KUDU) in the function portal and its skipping the build. Below is the log
9:55:46 AM Updating submodules.
9:55:47 AM Preparing deployment for commit id '5642d3aeec'.
9:55:48 AM Skipping build. Project type: Run-From-Zip
9:55:48 AM Skipping post build. Project type: Run-From-Zip
9:55:48 AM Triggering recycle (preview mode disabled).
9:55:49 AM Syncing 4 function triggers with payload size 452 bytes successful.
9:55:50 AM Deployment successful.
Deployment is happening when ever the code is checked in to Github. But its not picking the latest code. I did set the app setting WEBSITE_RUN_FROM_PACKAGE to "1".
What changes do I need to make to pick the latest build.
Thanks in advance
I have had a similar scenario and a similar experience, but I did not manually set WEBSITE_RUN_FROM_PACKAGE, though I found it set to 1. I assume it was set by the VS Code deployment, which first created the Azure Functions App. Then when I switched to using Kudu Continuous Integration, the setting was still around. I deleted that setting from Configuration, and now the problem is fixed.
I've got an ASP.NET MVC web app with a set of Selenium UI integration tests for it. I want to put this in Azure, and apply continuous delivery like this:
I commit a change to the Git repository
Azure notices the commit, gets the latest code, builds it, and deploys it to some test environment
Azure runs my unit tests on the code, and fails the build if any tests fail
Azure runs my integration tests on the test environment, and fails the build if any tests fail
If all tests pass, promote the code to production
This seems like a logical pipeline to me but I've struggled to get it working.
I've managed to get to step 3. by creating two web apps, e.g. Muppet and MuppetStaging. The MuppetStaging environment is automatically updated on each commit, so that's a great start. I edited the deploy.cmd to perform unit tests. This fails the build when the unit tests fail. That's great too.
The integration testing is the hard bit. Before the deployment has been completed, I can't integration test the current build - because it's not been deployed yet. The best I could do was integration test the previous version... but not the pending version. And even if I could, how would I then promote a successful build to production?
I know there is a "staging slot" concept but I don't want to have to press a "Swap" button to get my change into production, that would defeat the concept of CD. There is also an "Auto Swap" but again I don't think this takes integration testing into account.
I've been looking at tutorials relating to this kind of issue but no-one seems to have my requirements exactly... so either it's not possible or I'm doing it all wrong.
let me see if i can help and answer some of your question.
The integration testing is the hard bit. Before the deployment has
been completed, I can't integration test the current build - because
it's not been deployed yet.
There is post deployment hook that trigger after everything is deployed but still within the deployment process.
https://github.com/projectkudu/kudu/wiki/Post-Deployment-Action-Hooks
There is also an "Auto Swap" but again I don't think this takes
integration testing into account.
if you do testing with post deployment hook, if test failed which will fail the deployment operation, "Auto Swap" shouldn`t be trigger. if it does please do file a bug in Project Kudu
Microsoft Release Management tools seems to apply to your problem perfectly. If you haven't tried these already you should. They are now available as a service and also works great with Azure. Use Visual Studio Team Services (previously known as Visual Studio Online) to use Release Management as a Service and use Git as version control system.
Check these resources:
1. Official RM Page
2. Visual Studio Team Services
3. Continuous Integration via VSTS
with a local TFS 2013 server i'm trying to implement the Continuous Integration of a webservice to Azure. Now the build Definitions have the following:
/t:Publish /p:DeloyOnBuild=true /p:PublishProfile="xxx" /p:AllowUntrustedCertificate=true /p:UserName="yyy\$zzz" /p:Password="abc"
When a checkin occurs the build gets triggered, and i receive an Successful message. I then access the site on azure only to find the site wasn't updated.
i don't receive any errors. it almost seems like the deploy didn't happen.
if i do all this manually using the publish feature of VS2013, i choose the profile i got from importing the 'publish profile' file from azure. Then i see the changes. So my profile is good. It's just seems that the MSBuild is not doing the deploy after the build.
also in the LOG of the build. i don't see any references to deploying... not sure if i should see something there.
the only hint i get from the log is that the line:
Run optional script after MSBuild = 00:00
everything after that is also 00:00.
is there perhaps a setting that the autobuild needs to deploy? something more than what the manual publish would need?
so this odd problem was happening because the username included the domain. now there are several guides out there that indicate to use the user name found in the publish file you down load from azure. Which is what I did. But the web deploy didn't work until the domain was removed from the username.
/flp:verbosity="diagnostic" /p:DeloyOnBuild=true /p:PublishProfile="xxx" /p:AllowUntrustedCertificate=true /p:UserName="$zzz" /p:Password="abc"
notice the removal of yyy in username from the first post.
now i'm happily deploying.