I accidentally push the binary with staging key. Is there any real difference between the two stages(in terms of cli / library setting) aside from the obvious naming differences ?
Will I have problem trying to push updates using the staging env?
Code push Staging deployments are for debug builds (app-debug.apk)s while Production is as you guess, production releases (app-release.apk)s.
Refer to this text on their README here, Saying:
And that's it! Now when you run or build your app, your debug builds will automatically be configured to sync with your Staging deployment, and your release builds will be configured to sync with your Production deployment.
In your case I think you won't have any problems pushing updates with staging env as it a feature but they will be limited to app-debug.apks and not app-release.apk ones.
I would guess you wrote something like
code-push release-react <appName> <platform>
Then it said something like this
Upload progress:[==================================================]
100% 0.0s Successfully released an update containing the
"/tmp/CodePush" directory to the "Staging" deployment of the
"APP_NAME" app.
This is staging and should be used to test your app in the devices you installed the app-debug.apk bundle so you know how your update is going to work.
If you are okay with it, then you should promote it to the Production builds with
code-push promote APP_NAME_HERE Staging Production
Or Follow this answer here: How to update "Production" deployment using Code Push CLI?
to just release an update straight to production builds.
To answer your question:
Is there any real difference between the two stages(in terms of cli /
library setting) aside from the obvious naming differences
I can say - no, there is no difference and its up to you to decide how to build your workflow (although there are some practices in terms of how you can use it e.g. https://github.com/Microsoft/react-native-code-push#multi-deployment-testing).
The difference between two of this is more on semantically level and how you will use it depends upon you.
Moreover you can create arbitrary number of deployments if having a staging and production version of your app is enough to meet your needs.
You can use code-push deployment add <appName> <deploymentName> for this.
Also you can rename/delete deployments if it is needed.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed last year.
Improve this question
I want to design a wordpress development process like in following picture:
First I want to create a bitbucket repository for my Wordpress site. From this repository all our software developers should able to clone the site to their local machines for developing. For developing all developers should have one local database to test changes.
After a developer finished a task he should be able to push his changes to the repo. When a sprint is done I want to send all changes from the repo with Jenkins pipeline/job to the test environment. At this environment a tester should be able to test all new functions with a cloned database from the prod system (including the dev changes).
When all tests are successfully done I want be able to apply the database changes to the prod system (with a SQL script) and send all changes with an other Jekins pipeline/job to the prod system.
Do you think this can work? Whats with plugin updates? Can I setup environment variables for each system so the plugin updates can be just done on the dev machine?
I'm not sure if this could work because a plugin or plugin update creates a lot of new database changes and I think I need a tool who can display all changes like Sourcetree for git.
Is there someone who has expert knowledge with wordpress and this kind of development process and can share his experience with me?
Or do you think this process is not working with wordpress? If this is true it would be realy bad because I need a process like this.
Thanks a lot!
I don't really know Wordpress, but the process you describe is definitely possible (I've implemented similar solutions on Drupal and Adobe Experience Manager, for instance).
However...
It's hard.
In a CMS project, a change/new feature can include:
a code change (PHP, CSS, JavaScript)
a database structure change (e.g. a new table)
a database content change (e.g. a copy fix, or default/test content)
a configuration change
Working out which version should get what is really hard. You want a developer to commit a change, and have that change replicated on QA with test content - but once QA sign it off, you probably don't want to promote that test content to production. And config changes should probably flow between systems but with different values for each environment.
For managing the database changes, I've found a plug-in that monitors database changes; no idea how scriptable that is.
See WP Activity Log.
What I've done in the past in similar situations is write a script that creates the database definition for each change - so a developer can run that script, and commit it as part of their code change. It requires a lot of discipline, though - you can only modify the database structure by using the scripts.
The correct answer is yes you can do this. I know WordPress, Bit-bucket, GIT, SVN, Linux, Ubuntu exceptionally well. I have built a system very similar to what you describe and use it daily.
The problem stated is the CMS can get tricky. That is true, but you need to use the correct tools for the correct upgrades. So, WordPress ALREADY has versioning and revisions built into it. The DATABASE doesn't need to be involved at all
First off. The database doesn't need to be updated unless you are updating plugins. But for strict development no DB pushes are necessary. So have your developers check files in and out of Bit-bucket. When the lead developer approves the changes have him migrate / push to the MASTER BRANCH in your REPO. Inside of bit-bucket there is a tool called GIT HOOKS. You can trigger a php file on the server every time there is a push to the production branch. What the PHP file does is simply trigger the linux command GIT PULL which will update all the code on the server with what in on your PRODUCTION BRANCH. GIT PULL will also remove any files if files were removed etc. On the server you will have a "checked out" copy of the GIT repo and on linux the credentials after the first clone will be stored. Simply have your PHP file trigger a BASH script that does a GIT PULL. Done.
No matter how many developers you have there will always need to be a set of eyes that reviews the code changes and merges those into production. I.e. that is where the Lead Developer comes into play.
FYI. The only directories in your wordpress instance that needs to be in bitbucket is the THEME DIRECTORY and the PLUGINS directory. You DO NOT need to sync the entire WP install which is pretty large.
In the case that you would be building custom Plugins, again, it is just code that is stored in the plugins directory. If your custom plugins are built correctly and require the use of Databases then when they are activated they will immediately build the WP DB's that are needed. Likewise, correctly built plugin will also drop its own custom table when uninstalled.
You will need to sync the 2 below directories.
Plugins folder resides in: wp-content/plugins/
Themes Folder is wp-content/themes/SELECTED_THEME
Any additional questions just ask and I am here.
From my experience it is always better to allow each developer to have their own Branch and to setup the the Dev server a dedicated master branch for quality control. you can check out some documentation on how to set this up https://plixxer.com/docs/server-management/website-quality-control/
basically you want to have a live server and dev server. The live server should only ever pull from the REPO and and the Dev and coders can pull or Push from the repo. My team treats the dev server as a quality checking station. If the current live code is not up to our standards the entire dev is rolled back to what is live on the master branch. When code in the master succeeds our standards we pull from the master branch onto the live server. Each developer should have their own branch for testing on their local server. Let me know if you need some help on setting up a local environment with GIT.
You will want to make a distinction around "build" and another around "release". The workflow I understand is that developers call their local workstations "dev", and pull request their work to the develop branch (you may have already read through Gitflow). Then, using your choice of CI automation, you get the latest source into a build area and do that - build it. Check out Ansible. If you have BitBucket, maybe you also want to organize your sprint with the likes of Jira? Then you have pretty seemless integration of your sprint objectives with actual branches containing the relative work/source. Ansible can help you automate builds and releases to the point where you are doing daily builds, and running the unit tests across your builds in the various integration environments.
During builds, you would have different configuration files being factored in depending on the target environment. This is how to care for environment configuration. It is part of the build process, and ideally all configuration is possible through the build. For example, a connection string might be different across the environment if you are having different databases to isolate migration of schema changes. For example, in a Angular application you would execute ng b --prod to build production and this would bring in a production configuration file during build to change the connection string (for example).
More about configuration specific to environments... you can also include post deployment scripts that get deployed and executed after files are uploaded so that they will configure the environment as required.
Ask your questions below, and I will do my best to build this out into a comprehensive guide.
I have a CodePush app that has three deployments: testing, staging and production.
I have different app builds that align with these:
A build that does out to testers (testing)
A build that goes out to a group of preview users (staging)
A production build (production).
How does CodePush know what deployment it should be sending to a build?
And how do I set up my app to make sure the right build (e.g. staging version of app) is getting the right deployment (e.g. staging deployment in CodePush)?
The CodePush server knows which deployment you want to query for updates against based on the deployment key which is configured in the config.xml file or is passed to the call to sync (with the later taking precedence). If you want to generate three separate builds for QA/staging/production, then you simply need to make sure you update the deployment key that is set in your config.xml file before running cordova build to generate the APK or IPA file.
Unfortunately, Cordova doesn't really have a standard way of defining multiple environments, which would allow you to add your per-environment keys to the config.xml and have the right one be selected when doing an environment-specific build.
Depending on how your app is structured, you could also skip the config.xml file completely, and just pass the deployment key directly to the call to sync(). Then, you just need to make sure your app defines all the neccesary keys in a config somehow and loads the correct one for each build. You can take a look at this starter project for an idea of how this could be generally done.
I have configured CodePush for my dev, test and prod environments. But my application is a react-native one. I think the same will works for Cordova as well.
The important point is CodePush identify particular app by it's CodePushDeploymentKey. First you should create 3 channels on AppCenter for dev, test and prod. Then setup CodePush on those 3 environments and Get relevant CodePushDeploymentKeys.
Then you have to add those 3 keys for 3 different targets on your app. For iOS you can create 3 different targets on Xcode with 3 different plist files and add those different CodePush keys in relevant plist files.
For android you can create 3 different Product Flavors for dev, test and prod and then add DeploymentKeys on each flavor.
In this article I have explained everything step by step with all the screenshots and links.
I am a QA automation engineer and I am investigating docker as a potential way to run our tests.
Traditionally we have followed the git flow method where essentially where you have a dev and a master branch. Dev are constantly merging their new changes to the dev branch. When we wish to release, we will have a code cut off, where everything currently on the dev branch is deemed to be part of the next release. Script is then run to create the release candidate and this is deployed to staging. Any fixes that need to be done are made to the release branch and once ready to go to prod, new code is merged to master and deployed. Master is back merged to all branches so that everything is up to date. (described in more detail here: http://nvie.com/posts/a-successful-git-branching-model/).
So my question is with docker do you need to have this workflow? Im thinking of maybe having a workflow like describe below:
Dev start working on a new feature.
Dev pulls master, creates feature branch - does his dev work - unit tests pass, dev is happy for work to go to QA
Dev runs script to create release candidate (which would involve pulling master again in case new code has been merged to master by another dev),
Docker then spins up a container with multiple containers inside that (front end app, DB instance etc)
Tests (unit, api, selenium integration etc) are then run against this release candidate and if good deploy to production.
So do I need a staging env in the traditional sense where it is constantly available?
I think you're conflating two things: a continuous integration environment and a staging environment. Docker does make it easy to bring up a fresh instance of your entire stack for continuous integration (see drone for a good example), but generally you still need a staging environment that is always available to test against before deploying to prod. This staging environment should be running the same docker images that eventually get deployed to prod.
I need to maintain in parallel two version of the same applications. One for app store and one standalone (not app store) version.
My initial plan was to use the master branch for developing all feature that are common for both version. For standalone version my plan was to create a new branch, and in that branch to add a features for standalone applications, and the same for app store version.
Actually I tried my plan, but I have a problem with cocoapods. I have multiple dependencies that are common, but for standalone application I need to use a Sparkle framework. Now every time I try to merge master to one of my branches I have a huge conflicts with cocoapods files. That are very difficult to solve.
I was thinking about removing pods for my source control but than, when I switch branches I will need to do "pod install" every time.
Is there a better way to do this?
Thanks.
I strongly recommend to use Targets.
Look Apple docs and here.
I've never worked on tremendously huge projects and the workflow we use at work is check-out/code/compile locally to test/commit. I was wondering how a build server would change this process. How do developer test their code when the application is too huge to compile locally? They just code, commit and pray?
Absolutely not.
The developer usually has a build file which can build the project for him or her, which has some "targets" defined which do the testing. If you have a really big project, you may have certain portions of it precompiled for you, so you don't have to build the whole thing in one big chunk. You usually do your testing locally before you commit to your repository. Breaking the build in big projects can mark you as an object of ridicule and scorn. Breaking the build in really important, really big projects can be career limiting... ;-)
The build SERVER itself doesn't change this. The build server only runs your build file and the targets you tell it to.
There are also build components (I've just started using TeamCity - no affiliation) that allow "personal builds".
I haven't used it yet as we haven't got it set up properly but my understanding is that TeamCity allows running a build (and tests if they are any run on the server) with your changes before committing (and optionally the server will commit your changes if the build is succesful). in TeamCity this is called a Pre-Tested Commit.