I'm trying to figure out the CI portion that provided by AppCenter. I've implemented CodePush for my app and please correct me if my understanding is wrong.
We build the native android app and generate a signed apk.
Release the generated signed apk to playstore
execute command to upload bundle appcenter codepush release-react -a <owner>/<android-app> -d Production
The above are generally the way I understand CodePush and I've tested and working fine.
Now I've noticed that we can integrate our github project branch to appcenter, and whenever there is a git push, AppCenter will build it automatically and we can configure to release to playstore automatically.
Now the part I don't understand is, is this CI auto build by AppCenter actually nothing to do with CodePush?
If now my situation is only having updates on JS code side, actually when I git-push to repo, there isn't a need to auto-release to playstore right?
Correct, Build and Push are separate services in App Center. Build does the binary build of your app while CodePush simply updates the JavaScript and related code in an Apache Cordova or React Native. They're separate workflows and it seems you want to trigger them separate ways.
If you're using CodePush, you can't also use Build to auto build and deploy the native app to devices, you're duplicating work. I'm not an expert, but you probably want to manually deploy your builds whenever you make changes to the native side of the app (which should be rarely, right?) - like when there's major updates to the native framework or new plugins added to the native app
Related
I've built an app with expo managed workflow but then we needed a native module to be added to the app so I generated native project files using expo run:[android | ios] which works well on the development but I'm curious what could be the best approach to generate android release apk for the current project?
If I follow the expo build:[android | ios] I think my native changes won't be included in that build. But at the same time if I use gradlew assembleRelease then I think I will lose the expo OTA updates.
Sorry if my question seems a mess but I really need some guidance following that approach.:
Have you looked at Expo EAS - https://docs.expo.dev/build/introduction/
Problem:
Automation of application uploading after successful promotions. Typically easily done with APK and using gradlew scripts.
However, since App bundles are clearly the direction of the future and have many benefits we are moving to deploying with app bundles. We do not want to upload these manually.
I was wondering if anyone has run into this issue and how they resolved it? Initially, I hoping for a gradle wrapper script but I don't believe this will be available for awhile.
The route I'm currently heading is leading me to write a custom script to deploy using this following api.
https://developers.google.com/android-publisher/api-ref/edits/bundles/upload
Edit: https://fastlane.tools
I ended up choosing fastlane for now for simplicity and its robust reputation. Had aab uploading done in a matter of minutes. So far highly recommend.
EDIT: Ultimately, I ended up letting fastlane only handle aab uploads by getting the latest artifact from the successful build and moving it into an empty fastlane project. From there it requires minimum parameters/variables to be able to successfully deploy to google play WITHOUT needing to integrate fastlane into your Android Studio project.
I'm trying to deploy my first (very generic) app built using Ionic. According to the docs for deployment, I'm supposed to use some plugins. However, other sources suggest that I'm supposed to install Google's IDE called Android Studio and create an APK file.
I can't judge which approach is most valid nor if the one is an obsoleted version of the other. And we know how fast the wheels rotate in JS world...
NB. I'm confident in programming in general, I know Angular and have experience with deployments as such. In this case, I'm not looking to set up CI nor testing. I simply want my first app to be reachable through the store.
My suggestion would be to make a build: ionic cordova build android. Next sign it using the command line.
https://developer.android.com/studio/publish/app-signing.html
I am new to react-native app development. I wanted to know how can a developed app be shared between other developers without having a local dependency. Is an apple developer account needed for a test build to be shared in ios as well? How can the test build be created?. I wanted the build to be created and downloaded on any ios device or android for testing purpose and without having depending any of the local code changes.So the build downloaded should not get updated after any code change done after that.
Is there an easy way to do it?
To share a release build for Android please follow this guide Generating Signed APK.
But for iOS you gonna need a Apple Developer account, I don't know the whole process exactly.
We are struggling to come up with a good idea of how to integrate our build environments, now that we start using swagger-..codegen to generate API classes from our backend api for the android app, iOS app and the webclient.
Current situation:
we use several (private) github repositories
node.js backend: grunt build with tests and CI using cloudbased CI service- running codeGen for web- and android clients api access classes on sucessful builds, continous deployment to heroku test environement,
web Frontend, grunt build with tests and CI using cloudbased CI service and and continous deployment to herku test env.
android app, using gradle build and same CI, no continous deployment so far.
and soon there will be an iOS app as well...
This is private, non-OSS-code.
The requirement:
The different clients should be able to specify a dependency to the generated backend access libraries and get them during the build. The clients should be able to get the "latest" version or a specified fixed version, like with npm semantic dependencies. I could certainly enhance our build to upload the build artefacts to somewhere on successful CI builds, but the question is where to... what is the easiest way to set this up.
do we need one, (or even several) private artefact repositories (nexus, npm, bower, ...)
should we (ab)use github repositories to store the built artefacts in?
we could also publish the build artefacts to S3 or something similar...
any good ideas?
The only things you should really store are your separate "tasks" folders if you are doing some custom tasks, your grunt.js (.coffee), resources (that you may use for pre-build tasks -less,coffee/views, coffee/models all your custom stuff), and your package.json. That way any new developer just grabs those form source, and then runs npm install to pull all your dependencies from your package.json.
/resources
grunt.coffee
package.json
I then have some tasks that pull and run bower tasks (pull latest jqm, set that up, pull various libraries.)
As far as node_modules I wouldn't store those anywhere. This is a simple script / app I wrote that works almost end to end with compiling a JQM app, calling phonegap scripts, building the app and ultimately ending up with an xcode app package.
Maybe this will give you some ideas. So far I have found it best to do the above.
https://github.com/imaginethepoet/autojqm