I can't seem to specify only a singular group to a TestFlight build. Is there something else I need to do? There's a plus button in AppStore Connect, but every time I click it it just has me go through the Export Compliance steps and releases to everybody. Doesn't make any sense at all...
Related
For example, making changes to the metadata with new subtitle, keywords, and fixing grammars and spelling in the description, followed by submitting for review to Apple? Particularly with the build the was previously submitted and approved, rather than the building the current Xcode project.
For example when the state of the current project is not ready to publish to users, or development is still in progress or facing issues, but still want to make those changes to the metadata and publish as an update.
There’s an option to skip binary upload but appstoreConnect would still require a build to initiate a review submission.
Refresh NetSuite sandbox from production (code only)
I realize that we can refresh out sandbox from production but we don't want to refresh the entire sandbox, instead we want to refresh NetSuite SuiteScript, NetSuite Forms & UI Objects.
NetSuite's proprietary infrastructure/code and challenge it brings
I resisted asking this question for several weeks thinking it was too basic but it doesn't appear that way. After working with NetSuite for a while it has become clear that the line between source code and data has become blurry and it's my opinion this is exactly what makes refreshing code challenging.
I've also learned that storing NetSuite code in version control software is next to impossible (for all code) and this leads me to believe that my desire to refresh code only might be impossible as well. I have to wonder how IT shops that are encumbered by SOX compliance issues are able to satisfy auditors when it comes to controlling and modifying the business logic.
The real question and reason for refreshing the sandbox code
My motivation for refreshing sandbox code is the fact that we are encountering unexpected behavior in our sandbox accounts with certain forms (invoice & estimate) where custom tax fields (Ava-Tax) mysteriously moved from the items tab to a tab that contains transaction body fields! The form appears to not have been updated by anyone in over a year and there were no packages installed in the sandbox that might have broken the form.
If I cannot refresh source code is there a way to determine how a NetSuite form became corrupted knowing that the NetSuite Form is stored in a proprietary way and with no apparent source code available? I understand most of the NetSuite code is JavaScript that runs on both the server and client and there are parts that are unavailable to anyone outside of NetSuite.
Any solutions or suggestions are welcome and appreciated.
It is not at all impossible to store NetSuite code in Source Control. We use git to track all of our NetSuite source, and we follow a process similar to gitflow. Our master branch is always kept in sync with Production. Anytime we push code to Production, that gets merged from its feature/fix branch up to master and tagged as a release. If we want to roll back, we just revert master back a commit and upload the whole project to the File Cabinet. Then, if we want to refresh a Sandbox to match Production, we simply checkout master and upload all of that to the Sandbox.
Sandboxes themselves are much more difficult to keep in sync with a single branch in source because we are constantly developing there on separate feature branches.
If you do not already have such a system in place, all you really need to do is download the zip of your SuiteScripts folder from the Production File Cabinet and upload that to your Sandbox.
This isn't source control, but you can use SuiteBundler to copy items between accounts. SuiteBundler allows you to choose from a lot of things like forms, scripts and custom records. Later you can uninstall the bundle or dissolve it into the account.
It's not so easy to explain in few words, here but: You can use a deployment account to get things work properly. So you continuosly work on dev accounts and use multiple bundle / bundle version for follow branches/Versions of customizations. You update bundle from dev to deploy account only when a version is stable and production envs always install / update bundle version from deploy (not from dev). Since bundles are versionable and infinite, you can use git + dev + deploy account for manage Cvs. For get a versionable version of a form just add &xml=t in url in any form. But this is read only
Is there a way to configure TFS as follows:
When Build Fails:
Send an email to the breaker(s) only.
If build still broken after minutes, send an email to the team that says "Build is still broken"
Repeat ad-nauseum
I know how to do the first part. (Alerts Settings)
Is there a way to make it repeat sending (nag) until the build is fixed?
Not out of the box, but...
You can configure your alerts to send as text/html/soap. So if you spin up your own web service that does the nagging you can have TFS easily turn the nag of and on...
Set up a continuous integration build. That way, every time someone checks in code, the build will run and fail. Or hopefully, not fail.
I have two Team provisioning profiles which I need.
The automatic selection picks the wrong one for me at the moment.
I can't force it to use a specific one, because that choice gets submitted to svn.
Is there a way to influence the automatic selection?
I figured out that XCode picks the Team Provisioning Profile that was last added.
So, When you need to change the default picked profile, just reinstall it on your machine.
The defaults are chosen based on the bundle identifiers associated with each profile. You might think that the selector would choose the most specific identifier which matches your project, but this is not the case.
The selector chooses any profile which matches your project, with a preference for the most distant expiry date. The selection can therefore be shifted by generating your profiles in a specific order. The most recently generated profile will have a slightly later expiration date, and will therefore be preferred over older matching profiles.
(paraphrased from retrodreamer)
In the middle of developing an app, I was asked to switch to a different developer account, which resulted in adding a new app ID and creating new provisioning profiles for adhocs on the new account, as well as updating the XCode settings to sign with the new identity.
The problem is that somewhere, somehow XCode is keeping the old provisioning profile around.
I.e. I had a distribution profile "OLD". I created a "NEW". I deleted "OLD" from Organizer in XCode. When I build and archive, "OLD" REAPPEARS in XCode's Organizer, and the adhoc doesn't work for people.
I've tried doing a
grep -r "AD67EE83" *
in the trunk directory for the app, where "AD67EE83" is the profile id in the Organizer. I get a bunch of results in the build directory that look like this:
build/myapp.build/Adhoc-iphoneos/myapp.build/build-state.dat:N/Users/me/Library/MobileDevice/Provisioning Profiles/AD67EE83-BLAB-LABLA-BLAB-LABLABLABLAB.mobileprovision
build/myapp.build/Adhoc-iphoneos/myapp.build/build-state.dat:CProcessProductPackaging "/Users/me/Library/MobileDevice/Provisioning Profiles/AD67EE83-BLAB-LABLA-BLAB-LABLABLABLAB.mobileprovision" /Users/me/Documents/svn/myapp/trunk/build/Adhoc-iphoneos/myapp.app/embedded.mobileprovision
build/myapp.build/Adhoc-iphoneos/myapp.build/build-state.dat:x/Users/me/Library/MobileDevice/Provisioning Profiles/AD67EE83-BLAB-LABLA-BLAB-LABLABLABLAB.mobileprovision
build/myapp.build/Adhoc-iphoneos/myapp.build/build-state.dat:lSLF07#2#192"ProcessProductPackaging "/Users/me/Library/MobileDevice/Provisioning Profiles/AD67EE83-BLAB-LABLA-BLAB-LABLABLABLAB.mobileprovision" build/Adhoc-iphoneos/myapp.app/embedded.mobileprovision303990620#303990620#0(0"0(0#0#108"/Users/me/Documents/svn/myapp/trunk/build/Adhoc-iphoneos/myapp.app/embedded.mobileprovision8628715392#445" cd /Users/me/Docume <com.apple.tools.product-pkg-utility> "/Users/me/Library/MobileDevice/Provisioning Profiles/AD67EE83-BLAB-LABLA-BLAB-LABLABLABLAB.mobileprovision" -o /Users/me/Documents/svn/myapp/trunk/build/Adhoc-iphoneos/m0#p.app/embedded.mobileprovision
(I replaced the actual ID with BLABLA there, in case you wonder about that.)
In any case, OLD is pulled out from somewhere and restored and used. Insane. I deleted in Organizer and searched my disk for that AD... thing and found a few files in /Users/me/Library/MobileDevices/Provisioning Profiles/ which had the same names.
I deleted those and it still pulls them out from somewhere when i Build & Archive. In fact, those files are put back in that directory as well.
I've gone through all the settings trying to find any reference to this AD... profile, but there's none anywhere.
OLD is tied to "com.oldcorp" and NEW is tied to "com.newcorp" -- doing a grep 'newcorp' reveals
myapp-Info.plist: <string>com.newcorp.myapp</string>
Doing a grep 'oldcorp' gives no results.
Any ideas where it might be referring to this old invalid cert? (It's even removed from the developer portal, so I don't think it's possible for it to download it from Apple directly.)
Update: building and archiving ANY project results in the resurrection of the "oldcorp" distribution profile, so it's not related to my project. Problem remains though - adhoc is non-functional.
Solved this by recreating a project and manually putting code in. Long term solution is in answer below.
I create new User accounts on my Mac when dealing with different developer accounts to prevent XCode caching from creating these types of messes.
That might still provide you with a solution. Create a temporary fresh new User account, install only the private keys, certificates and provisions needed for the new developer account in the new User account, make sure not to use any shared user directories in your build settings, check out your project from source control into the new user account, and run Xcode for your Ad Hoc builds there.