I keep seeing the sandbox 'switch' every time I log into salesforce, no matter which environment I'm logging into (prod and pre envs usually).
What's a sandbox in salesforce? What does it mean to use a sandbox or not using it?
Additionally, on libraries like https://github.com/heroku/salesforce-bulk or https://github.com/simple-salesforce/simple-salesforce, sandbox is a boolean which you specify to log into it.
Is it equivalent to an autocommit connection (regarding relational databases)?
A sandbox is a separate environment from the main production environment that copies the configuration (and sometimes data, depending on the type of sandbox), and is designed to be used for development, testing or training.
When logging in, you need to specify whether the environment you are logging into is a sandbox because the sandbox login service is hosted at a separate domain; test.salesforce.com vs login.salesforce.com.
A sandbox isn't related to an autocommit connection. I would say it is equivalent to a development environment or a test environment.
For more information, I would recommend looking at the Development Lifecycle Guide
Sandbox is in short: It is Dev or Test or Integration environment for your production.
It is always recommended to develope your code in Sandbox then deploy it to production.
Refer the trailhead: https://trailhead.salesforce.com/en/content/learn/modules/declarative-change-set-development/plan-for-changes-to-your-org
Related
Problem
I created an app and deployed it via AWS Amplify. The app works, but every time I try to do an operation which uses my database I get an error. The peculiar thing is that when I am developing on localhost and connecting to the database, everything works.
Debugging
I checked whether the environment variables are set correctly and they are. When checking the cloud logs, I can see this error: code: 'ER_GET_CONNECTION_TIMEOUT'.
Could this be a problem with the security group or something else? There are no problems connecting from my local ip. There is only one inbound rule specified:
I am not really well versed in all the IAM management stuff, so there is a good chance that I have messed this up. Any hints or help are very welcome. Thanks in advance.
If you amplify mock function .... test a Lambda, I believe it runs using the permissions of the amplify-cli user and not necessarily the Lambda's actual permissions.
Try amplify env checkout prod so your local environment is pointing to the 'production' environment on AWS. Test the front-end (carefully, knowing you're making changes in production) and see if that works.
You'll probably need to log out of the front-end website and log back in using a production user.
If that fails, then I suspect something is different between your dev & prod environments. Look at your environment variables. Make sure you didn't hard-code any table names -dev instead of -${process.env.ENV} etc.
IF the above test does work, then consider the differences between production and development environments. If everything is managed by Amplify, then the should be the same. If you have some pre-existing resources, then you'll need to examine the permissions resources have to talk to those resources. Did you grab an ARN from somewhere in your dev and not from prod? etc.
I have a Quarkus application already deployed on Google Cloud Run.
It depends on MySQL, hence there is an instance started on Cloud SQL.
Next step in my deployment process is to add keycloak. From what I've read the best option seems to be Google App Engine.
The approved answer in this question gave me some good insight of what needs to be done ... mostly.
What I did was:
Locally I made a sub-directory in the main project.
In that directory I added the app.yaml and the Dockerfile (as described here for instance).
There I executed the said two commands: gcloud init and gcloud app deploy.
I had my doubts about this set up and they were backed up by the error I got eventually:
ERROR: (gcloud.app.deploy) INVALID_ARGUMENT: The first service (module) you upload to a new application must be the 'default' service (module). Please upload a version of the 'default' service (module) before uploading a version for the 'morph-keycloak-service' service (module).
I understand my set up breaks the overall structure of the project but I'm not sure how to mix those two application with the right services.
I understand keycloak is a stateful application, hence cannot live on Cloud Run (by the way the intention is for keycloak to use the same database instance shared with the application).
So does any one know a more sensible set up, or what can I move in mine in order to fix it?
In short:
The answer really is in reading the error message (thanks #gaefan) - about the error itself it explains enough. So I just commented out the service: my-keycloak-service line in the app.yaml (thus leaving gcloud to implicitly mark it as the default one) and the deployment continued.
Eventually keycloak didn't connect to the database but if I don't manage to adjust the configurations that would probably be a subject to a different question.
On the point of project structure and functionality:
First off, thanks #NoCommandLine and #guillaume-blaquiere for your input!
#NoCommandLine the application on Cloud Run is sort of a headless REST API enabled backend. Most of the API calls are secured by keycloack. A next step in the deployment process would be to port an existing UI (React) client on the Firebase hosting (or on another suitable service - I'm still not completely sure which approach is best) and in order for the users to work with this client properly they must make an SSO through keycloak first.
I'm quite new to GCP and the number and variants of the available options are still overwhelming to me - one must get familiar with the nuances but I guess it takes time. So I'm still taking suggestions on how to adjust my project structure to fit better the services stack. Thanks!
I need to test my wordpress install which I have set up already and deployed. I have to debug, so waiting 10-15 mins for it to deploy to test one thing isn't going to work.
All they mention in their docs: https://cloud.google.com/appengine/docs/flexible/php/testing-and-deploying-your-app#running_locally
Running locally
"To test your application's functionality before deploying, run your application in your local environment with the development tools that you usually use."
That's it. How can I actually serve my wordpress application? My tools I "usually use" are xampp...very confused.
Can someone help me run my flex env locally to test it?
You may want to take a look at this for the initial tests for your PHP application. You would have to install composer on your shell for it, if you haven't done it already.
Then, for the WordPress application, follow the steps described here to test the Cloud SQL instance that is associated to the app. There is also the possibility to test all the updates you want to apply to the WordPress side. Skip the deploying part until you confirm all your changes work for you, so that you don't have to wait all that time for a deployment.
https://cloud.google.com/appengine/docs/java/tools/devserver
States nowhere about the SystemProperty.environment.value() value, what the default setting is, if I can set it etc.. The only info is here https://cloud.google.com/appengine/docs/java/javadoc/com/google/appengine/api/utils/SystemProperty which states Global system properties which are set by App Engine.. As said, what is stated when.
I'm guessing from this question How to run your app in production mode on development server in google app engine-java that if a server is started from the sdk the value is development.
It's frustrating to guess this without any official documentation on the matter. Can anyone shed some light on the topic?
This returns an ENUM which would either be Development or Production. In practice this means the server is running either deployed on Google servers or locally on localhost.
More info on: https://cloud.google.com/appengine/docs/java/javadoc/com/google/appengine/api/utils/SystemProperty.Environment.Value
So, in the past, when I've used Google App Engine, I've utilized their wonderful version system to create an integration, staging, and production environment. When we're ready to go live, we set the production environment to be the default, and it starts receiving traffic at the standard AppSpot URL (myapp.appspot.com), if it's not the default you have to manually go to the version itself (dev.myapp.appspot.com) for your testing. This is an awesome system for a pre-prod deployment with a full test.
However, I just went to do an App Engine deployment today and got this warning:
WARNING: Soon, deployments will set the deployed version to receive all traffic by
default.
To keep the current behavior (where new deployments do not receive any traffic),
use the `--no-promote` flag or run the following command:
$ gcloud config set app/promote_by_default false
To adopt the new behavior early, use the `--promote` flag or run the following
command:
$ gcloud config set app/promote_by_default true
Either passing one of the new flags or setting one of these properties will
silence this message.
So, apparently, very soon Google will make it so that for every deploy of any version, they will just automatically promote that to be the default and be accessible at the standard AppSpot URL.
My question is, what's the benefit in this? I can't use this for A/B testing (since there's no B in the equation here). I can't use this as a pre-prod test, because it takes over my environment right away. Why would I want any version I push up to be the default? Am I missing something? Was I using versions wrong?
I'm just genuinely curious.