We've been trying to implement a multi environment solution with RNFirebase, but splitting out the firebase projects hasn't seem to done the trick.
We have separated the projects into dev and prod environments, but they both share the same package name/bundle ID, and it seems to have caused issues on our production environment causing people to see a reCaptcha on iOS, that causes a blank screen that the user can't get past.
As for the question, how can we go about separating the environments on the FE side, whilst keeping the bundleID and package names the same(If that is possible)?
Related
Unfortunately, I am not much aware of these two terms and I have a feeling that I need to know more about these as I am approaching an app release.
so, if I am running the app on development mode am I not using exactly the same code as production? Like what does it actually change and whats the purpose of it?
If it's in the sense of server than that's understandable, I don't wanna mess with the server that's being used by the users, so I guess i need to connect to a second server - development, however, I am interested to know what does it change in my code? I am still gonna use the same locally stored project right?
Sorry for being so naive!
The development build is used - as the name suggests - for development reasons. You have Source Maps, debugging and often times hot reloading ability in those builds.
React Native includes some very useful tools for development: remote JavaScript debugging in Chrome, live reload, hot reloading, and an element inspector similar to the beloved inspector that you use in Chrome.
The production build, on the other hand, runs in production mode which means this is the code running on your client's side. The production build runs uglify and builds your source files into one or multiple minimized files. There's also no source maps or hot reloading included.
Further more , Production mode is most useful for two things. They are
Testing your app's performance, as Development slows your app down considerably and Catching bugs that only show up in production.
Hope this might help
https://docs.expo.io/versions/latest/workflow/development-mode/
After digging in farbic docs alot and exploring multiple stack overflow questions I don't see any information on how to setup Fabric crashlytics for dev(beta) and production both.
Basically I want beta build to log events on separate Fabric app and production build to log on different Fabric app.
Currently Fabric puts its api key in manifest which I think can be controlled for multiple environments but they put secret key in app->fabric.properties file which I don't see can be overridden for different environments.
Any help will be appreciated if someone has achieved this.
Thanks for reaching out. Fabric lets you separate by bundle ID or package name OR API key. If you alter either of these between your build types it'll report to a separate dashboard.
Thanks!
Originally I ran a local server on my PC in order to make my django REST api available for my React Native app to reach out to through my computer's ip. So I had a base url hardcoded into my js network utilities as http://10.0.0.xxx:8000/api/ which I used as the basis for all my network calls. Recently I deployed my backend to Heroku so that I could demonstrate my app when away from my computer. So for now I just made a second hardcoded base url of https://my-cool-app.heroku.com/api/ which I manually flip back and forth between in my js code depending on if I want to use my local server (for debugging while devving) or the remote server for demonstration (and by "manually flip back and forth", I mean I literally change my code to point to one or the other).
I understand this is a terrible way to go about things and that I'm missing some major pieces to the puzzle that probably apply not just to RN projects but to most full stack projects where the frontend and backend are not hosted on the same server. I know I can look for the __DEV__ flag to see if I'm working in a debug or release version, but then would I have to keep two versions of the app on my phone somehow? Also, does it even make sense to keep my base urls hanging around on the front end, or should they be dispensed from the backend in some way instead?
I personally use :
https://github.com/zetachang/react-native-dotenv
for my environment variables like my backend api and other configs based on the env.
Since it's similar to many backend libs like django or laravel, i absolutely love this library for managing environment variables :)
Is there a way to determine if the App is running locally or has been deployed through the App Store?
I would like to test the trial mode functionality using Windows.ApplicationModel.Store.CurrentAppSimulator during development but default to Windows.ApplicationModel.Store.CurrentApp if the app has been downloaded from the store by a regular user.
I don't believe this is easy to do. I suspect the easiest way is through conditional compliation, and produce a specific build for submission. You can use Ajaxmin for this, but that would require a little bit of setting up.
Given that an application when deployed is supposed to be in distinguishable no matter it's mechanism, I don't think this:
http://msdn.microsoft.com/en-us/library/windows/apps/windows.applicationmodel.package.installedlocation.aspx
Will help. It will plausibly tell you if you've been deployed from VS (which deploys loose files), rather than as a package.
I'm very new to C.I. but I have recently inherited a project where Team City has just been implemented and I'm slowly getting my head around it. One thing we would like to do is run some Selenium Tests as part of the build process. I've created the selenium tests and can run them successfully via nunit-console on my development machine. The build server builds the project and then deploys it (A web forms application as it happens) to a staging server.
Before each selenium test we set the database to a known state, i.e. to only have certain records in place - that way each test is independent of the others. The problem is the staging server will be used by real "human" testers so this would cause them a problem with the database continually being reset (records being removed etc.) The question is should I really also deploy the application to a virtual directory on the build server and run the selenium tests against that and only deploy to the staging server if those tests pass?
Or have I got this stuff completely wrong? If so how do you do it in your organisation?
I suggest that you do not mix your automated and manual testing by allowing your testers to access the server that is staged for your automated tests. This can cause false negatives both in your automated and your manual tests. These 'bugs' are indeterministic and more than likely never reproducible (a very bad news). This will cause you a lot of unnecessary 'bug reports' and build failures.
So here is what you can do...
In addition to your current setup, you can create an extra staged server for your manual testers. This is the least you should do. You should probably create several of them, one for each tester.
And here comes the rant...
In my current project we recently found out that our testers (we had ~10 of them) reused one server. They claimed that since our app is going to have multiple concurrent users, it was a good idea that while they are testing the individual functionalities, they are also testing how these functionalities act while multiple users are working on the same server. WRONG!
If multiple users are a concern, there should be test cases for the specific concerns. If functionality#1 can interfere with functionality#2, it should be specifically tested and not just be 'tested-by-luck'.
Before this was explained to our manual testers, we had many false bug reports due to the fact that one tester was simply stepping on another tester's toes. (e.g. tester1 deleted a record that tester2 introduced to the system, etc...). This created a lot of unnecessary bug reports and these bugs were never reproducible.
Sorry about the rant, I hoped this still helps :)