I used fastlane to upload to Beta, i put promote_to_track : production filed, is this flag will uploaded to production directly without testing.
If this is the case it will upload to beta and production directly why this is promoted.
Please help me to understand this point if i put promote to production it will be uploaded to production dictrly without review or testing, please advice
Related
When I open my Instant Games app I get Your instant game doesn't have a production version error.
How can I specify such production version without Web Hosting (thus uploading a .zip archive)?
Instant Games are always hosted by Facebook.
It sounds like you simply missed to perform the necessary steps as they are outlined under https://developers.facebook.com/docs/games/instant-games/test-publish-share#testing, specifically the “Productionize the Build” step:
To test the upload in a production environment, the build must first be staged for production. Click the "★" button to push the build to production.
I am new to FastLane. And I'm trying to build our app. I did successfully able to export the IPA file of our app but I'm not sure which branch FastLane used to build the app. Would it use the Master branch? or would it use the branch I'm currently on (if I open the SourceTree and select a branch)?
I searched over the SO but I didn't found any information that could answer my question.
This all depends on how exactly you set up fastlane and your lanes of course, but by default fastlane and build_ios_app/build_app/gym work on the local checkout on your hard drive (so what you currently have checked out via git/Sorucetree).
You can also of course make fastlane check out a specific branch in your lane in your Fastfile by calling the appropriate action - pretty much anything is possible.
I'm trying to fix up a broken Travis CI build script on a repo I was added to as a contributor. Everything works fine in the actual build, but trying to upload the build results to GitHub is broken.
The .travis.yml file contains an OAuth token which it puts into the Environment, and at the end it runs a script that retrieves this environment variable and uses it to upload the build output to GitHub. This is failing with a 401 Unauthorized error, which means the token is probably no longer valid.
I didn't write this up, and the way this works kind of bugs me. I'm not comfortable having authentication information in the repo, publicly accessible to the world, so it's just as well that this token is expired. But as I look things over, I don't see any better way to do this.
I need to do one of two things, either have the Travis build machine upload the build result to GitHub, or download the build result from Travis and upload it myself. Unfortunately, neither one seems to be a good option. No matter where I look on Travis CI's Web interface, I can't find any download link to retrieve the build results, which seems to rule out the second option. As for the first option, it doesn't appear that there's any way to perform the upload without the build machine having authentication information from the repository.
I can't be the first person to notice how problematic this is. I figure it has to be solved somehow; I'm just not sure how to fix it. Does anyone know how to resolve this?
I would like some guidance when working projects with Moovweb. I'd like to understand what are some of the best practices at managing my Moovweb projects on Github. Specifically how to move them and maintain them from development to staging to production.
Really appreciate the information.
J
I'd check out some of the advice here that walks you through how to setup a professional development environment:
https://console.moovweb.com/learn/training/building_a_site/project_setup
The main idea is to setup your project so that it has 3 git remotes. A git remote is simply a URL where your code is being hosted.
origin: This remote will be where you and your developers host your code base. You’ll coordinate changes to your code here and manage different branches and bug fixes during development.
stage: This remote is where you’ll deploy your code base for testing. This will be a Moovweb Cloud URL that actually builds your code live so you can QA it before you put it on your production site.
production: This remote is where you’ll deploy your final production site that has been tested and approved for public use.
Then the release process would be as follows:
Test your changes locally in the browser
Push those changes to staging to QA them and make sure they work properly in a production environment.
Push those changes to Github so that other developers working on the project will have the latest code.
Push to production.
I have an automated deployment process for a Java app where currently I'm building the app on a build machine, checking the build into scm, and having the production machine pull the build artifact (which is a zip) and through ant move the class and config files to where they're supposed to be.
I've seen other strategies where the production machine pulls the source from scm and builds it itself.
The thing I don't like about the former approach is that if I'm building for production instead of staging or dev or whatever, I have to manually specify the env in the build. If the target server were in charge of this, though, there would be less thought and friction involved in the build. However, I also like using the exact same build as was being tested on staging.
So, I guess my question is, is it preferred to copy the already build/already tested app to production or to have production build the app again once it's been tested.
If you already have an automated build system that is creating a testing build, how hard is it to extend that so that it builds both a testing build and a production build at the same time. This way you get the security of knowing they were built from the exact same checked out source and you have less manual labor. I really cringe at the idea of checking built artifacts into SCM!
I always prefer keeping as little as humanly possible on a production server - less to update, less to go wrong.