There's been a lot of changes to VS AppCenter and I'm not clear if it still pushes updates to the app to end users. I see a mention of pushing updates to beta testers but not clear if I can push my latest versions or updates to actual end users. Does anyone know definitively if update pushes to end users is still a feature.
Related
We have multiple small projects within our organization. Ever since we adopted Azure DevOps recently, we started creating the individual Azure DevOps projects for everyone of these projects. The ALM process has been going on very well, with end to end traceability established with in the online tool.
However, as we get to end of each of these projects, we started to realize that these individual project and its code needs to be maintained further for the bug fixes and hotfixes. Unfortunately, Microsoft doesn't give a clear road-map for a project code, once it is completed.
Since we have a separate devops project for all the maintenance applications, this becomes much more confusing.
So, Could you suggest me on what is the best practice to maintain the code after the project is completed? Here are some options that I can think of.
Just keep the code in the same project and keep doing the bug fixes there. But, this will create an administrative nightmare to keep track of multiple projects for our maintenance application landscape (especially, since we already have a single projects with multiple repos and teams maintained).
Migrate the code from the completed project repository to the maintenance project. But, this again is a migration from one repo to another. So, I am not sure if this is right.
I'm working on a action on google project, I release the alpha version then the beta version.
But I need to do some changes before to deploy in production.
So my question is:
Before deploying in production, Is there a process review again ?
Yes,
Whenever you are submitting your action to production, there will be review. No matter what changes you have done, what amount of data you have changed.
When using a Git-backed ADFv2, I'm trying to detect when a user publishes directly to the Factory vs when a user publishes to the Factory via the Git collaboration branch.
I've tried looking at the Activity Log, but I can't distinguish between events from a Git Publish vs events from a Direct Publish.
I see that this information is at least visible in the UI. Is this persisted anywhere? Is there any way to obtain this message?
Is there another way to do this?
According to my observation, the messages don't persisted anywhere.It is just temporarily stored in the browser's cache, and disappears once you refreshes it.
In the ADF active log,you only could see the epitomize of operations.
I supposed that you only can distinguish between events from a Git Publish vs events from a Direct Publish in the Dev ops page.
You could see the direct publish will leave the comments in the commits list.
And if you release any updates in the Git publish, you could remark some prefix,like --from git---.
I've been successfully using Git deploy (via Kudu) to a couple of Azure websites (e.g., beta/prod) for several months, and it's worked quite well. Starting today, I noticed that when I push to the appropriate respective git branch, my Azure websites will supposedly deploy - i.e., the deploy kicks off, everything builds, all my tests run, and the Azure management portal swears up and down that it's deployed my website - but ... nothing happens. My websites don't change. (Beta and prod pull from different branches of the same git repo, but no matter which I push to, none of the changes included in the latest push show up on either website.)
There are no errors or any other indication of a problem in the logs. The Azure portal detects the git pushes, runs the deployments, and swears that they've happened successfully. But the changes - some very simple ones, i.e., text on a certain page - simply aren't there.
This is the sort of thing that I'd normally contact Azure support for, but my subscription doesn't include tech support :-(. The Azure site recommends asking here on SO, and hence my post.
Any suggestions for further troubleshooting this?
Well, I don't know what was triggering the problem, but resetting the website - by adding a bogus key/value pair to the configuration, and saving it - triggers the website(s) to pick up the changes. Apparently the underlying issue is that the Kudu deploy doesn't seem to be triggering the website to reset itself. I'll add more details in the future if I run into the problem again.
[Edit 2013-10-15 - Today, deploys seem to be working normally again. My guess is that it was some sort of transient Azure bug that's now fixed.]
I have an app that I have been working on and I did a bunch of changes and then realized later I should have been adding versioning to the Core Data model. So I'm trying to go back and do that now.
Basic information:
I think everything I've done would fall under the lightweight migration feature.
I'm using git
I already have the app in user's hands
My question is: what is the easiest way to do this?
Since I'm using git, could I simply checkout the data model from when I submitted it to apple, create a new version for it, and add my changes? My main fear with this idea is that my project.pbxproj file would be incorrect. Would this an issue? Is there a way to get around this?
IF I could do this, would I need to recreate my class files or would that be ok (assuming I get it back to being identical to what I currently have).
IF I CAN'T do this, then what can I do? If its a matter of starting from the last version I pushed to Apple and applying changes I guess I should look into doing it with git rebase, right?
This has nothing to do with git.
You need to create a new version of your app, provide the new data model, set it for lightweight migration and then release it as an update. Core Data will basically assume that any model without version info is version zero and attempt a migration to the new version.
When the user downloads the update, the automatic migration will trigger the first time the app runs.
Creating a new version means nothing more than changing the version number in the project info. When submitted, that will trigger the upgrade and the migration.