We are following two ways for code deployment:
Org Deployment model Using Gearset (building package and deploying using quickdeploy option).
Salesforce DX - ( 20-30% dev groups are using this approach).
Now: Under option 1 we are ready with our built and package is ready in Prod for quick deploy but there is a DX deployment in production before us.
My question is - will DX deployment will remove my quick deploy build available in Production? Please help as I am new in Salesforce DX.
Thanks.
Build is created for the deployment in PROD via Org Deployment flow.
No, you cannot quick deploy after performing another deployment, nor should you in any case.
From Monitor Deployments in Salesforce Help:
If you perform a deployment after a validation, whether through Quick Deploy, a package installation, or a regular deployment, all validations no longer qualify for quick deployment. Revalidate the set of components to quick-deploy.
Your Apex test passes from a validation run are no longer meaningful after you perform another deploy because the target environment has changed. You need to revalidate to determine that your deployment still works when integrated with the changed target environment.
Related
We now have two applications with two differents git respositories. The first one is in ReactJS for the front and the second one is in C# (Web Api 2) for the back. When we want to deploy on Azure, we build the front and we copy the output files to the c# project (web api project). We deploy the web api application from Visual Studio in Azure thanks to the deploy menu.
It's a little bit boring and sometimes we have errors when we change by hand the parameters relative to our differents environments.
We would like to automatize all these tasks with Azure Dev Ops. Have you ever done this kind of stuff ? And how ? Sorry, if this question seems stupid but i can't find a tutorial to build when the front and the back are not in the same git repo. Thanks in advance for your help.
You can follow below steps to build and deploy your application. I can only give a general idea and steps. The main idea is to get your front and backend source code together and build them in the same pipeline. The configurations and parameters for each tasks in the build pipeline need you to specify according to your project.
Below steps is shown in classic view pipeline. Check here for yaml view pipeline
1,Sign in to your Azure DevOps organization and navigate to your project.
2,Go to Pipelines, and then select New Pipeline, and select Use the classic editor to create a pipeline without YAML at the end of the page.
3,Walk through the steps of the wizard by first selecting as the location of your source code.
4, select a source to specify where your code is located. And continue to choose a template, here i choose ASP.NET Core(.NET Framework) template.
5, Add a powershell task to the top of your pipeline(the tasks can be drag and drop to reorder) to run the git commands to clone your front react.js code into same source folder of your backend c# code.
If your code is hosted in azure repo git. You can add below scripts in your powershell task. Make sure Allow scripts to access the OAuth token is checked
cd $(Build.SourcesDirectory)
git clone "https://$env:SYSTEM_ACCESSTOKEN#dev.azure.com/{yourAzureorganizationName}/{yourProjectname}/_git/testrepo"
6, add npm install task and npm custom task to build your react.js, You need to specify the path of Working folder that contains package.json to the folder where you cloned your reactjs code in the above powershell step. you can check steps here for reference.
7, Add a copy file task before task Visual Studio build to copy the output files from building react.js to the your c# project.
8, Configure the necessary path and parameters for Visual Studio build
task and Visual Studio test task to build and test your backend c# code.
9, Add an Azure App Service deploy task at the end to deploy to azure.
You might need to add other additional tasks to build your projects. You can also move your deployment task to release pipeline.check here for more information.
There are lots of examples and learning materials that you can find online about how to create build pipeline and how to deploy your application to azure. I suggest you can follow one example to create your build pipeline for c# project and try to edit your existing pipeline to integrate your react.js project.
Here is microsoft official documents for you to check it out. Hope you find above helpful.
Here, you can find the steps to build and release two web apps (hosting web api) and the relative front developed in ReactJS. Here's our goal :
In Azure devops, we've created a pipeline using the classic editor :
We selected our git repository and this template :
After a step of creating tasks, we obtain :
We'll describe some of these tasks. For example :
/p:SkipInvalidConfigurations=true /p:DeployOnBuild=true /p:WebPublishMethod=FileSystem /p:publishUrl="$(build.artifactstagingdirectory)\appRetailLab" /p:DeployDefaultTarget=WebPublish
Once you've build the two web applications, you've to copy the front files in web applications. There're two tasks for that :
At last, you publish your artefacts in the drop directory within the build.artifactstagingdirectory :
The release :
Our release is not too difficult :
We use 4 tasks :
Replace Token is a very usefull plugin. You can replace a token (defined by a template) by a value defined in the release. We use this plugin to replace our token in the front part of our applications (js files).
To add token in our reactjs application, we use dotenv npm package.
For the web.config parameters don't forget to check XML Variable substitution in your deploy task.
That's it.
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.
I am using IntelliJ IDE to develop Spring Boot services with Maven and using Google Cloud Tools plugin to deploy to App Engine Flexible. While I use the following (to connect to local) and run the app. locally, it works fine (in application.properties).
spring.datasource.url=jdbc:mysql://localhost:3309/test
However, when I try to deploy to the GAE with the following (in application.properties),
spring.datasource.url=jdbc:mysql://google/test?cloudSqlInstance=[cloud-sql-instance]&socketFactory=com.google.cloud.sql.mysql.SocketFactory
when trying to build the project before uploading to GAE, it throws UnknownHostException: "google".
Questions:
How can I create different configurations for various environments (dev (local) / qa(gae) / production(gae) ) and deploy to those environments with the corresponding environment values?
When doing the build from the IDE, it validates the DB connection string (which points to the cloud sql instance) and throws an exception if it is not reachable (however it will be from the QA / Prod environment if the build is successful). How to resolve this case?
Any help on this would be greatly appreciated.
Thanks in advance.
You need to use Spring Profiles. Please read all the information in the documentation for an extensive explanation.
Briefly:
Spring Profiles provide a way to segregate parts of your application
configuration and make it only available in certain environments
Now, onto the problem at hand. It can be solved by introducing a "local" profile for you development and leaving the "default" profile to be used in production (GAE).
application.properties
# this file is for the "default" profile that will be used when
# no spring.profiles.active is defined. So consider this production config.
spring.datasource.url=jdbc:mysql://google/test?cloudSqlInstance=[cloud-sql-instance]&socketFactory=com.google.cloud.sql.mysql.SocketFactory
application-local.properties
# this file is for the "local" profile that will be used when
# -Dspring.profiles.active=local is specified when running the application.
# So consider this "local" development config
spring.datasource.url=jdbc:mysql://localhost:3309/test
# In this file you can also override any other property defined in application.properties, or add additional ones
Now to run the application while developing all you have to specify in IntelliJ in your run configuration is -Dspring.profiles.active=local under VM options, or if you're using a "Spring Boot" run configuration, you can just add local in the Active Profiles field.
And on GAE, do not specify any profiles at all and the defaults will be used.
I have been tweaking my environment in Google's App Engine to have several instances of my app for testing and production. However I am uncertain if the intended use of versions applies here.
App background:
- Node.js express app configured on app engine, using Cloud sql.
- 2 modules:
- - default/main - front end code code and API
- - workers - separate app that has a variety of workers
- Redis to keep track of the queue, kue.js for implementation
I was under the impression that I could use versions here, so that I keep only 2 modules, my default one and a workers module. Each will then have 2 versions, staging and production. The commands to push each one would then be:
gcloud preview app deploy --version staging --no-promote
gcloud preview app deploy --version production --promote --no-stop-previous-version
That is all separated well, and perhaps the intended use of versions. However, what I can't achieve with this is no downtime. What seems to happen is that the old machine is tore down then the new one build up, resulting in 3-4 minutes of down time during deploys. As opposed to keeping the old until the new is finished and then just rerouting. Note, the production version in this case should always have 100% of the traffic.
What I found to work well is to keep a module for each version, so I end up with 4 modules (default, default-staging, workers, workers-staging) and no real versions specified during deploys. When deploying with this, there is no downtime, but old versions are kept running:
gcloud preview app deploy --promote
I have a helper script to delete all versions that get 0% of the traffic. Is this the correct approach for setting up separate environments? Just looking for some feedback in case I am missing something obvious.
By deploy, I assume they mean code changes are pushed to production?
If I had 2 or three devs working with me on a project, what is to stop them from pushing changes that break the production site?
What checks and balances do we have to avoid such error? Do you setup a staging and production environment in GAE, having someone manually verify everything appears to work before making live.
If you want to limit individual devs doing uncontrolled pushes to the code.google.com (from which the deploys happen), then arrange for one and only one local repository be the local repo-of-record, and only configure that one to know about the source.google.com 'origin' server. Integrations are pulled into that repo, and (when you're ready) push to deploy from there.
Here's how it works under the covers. When you use gcloud to set up a project, it modifies default/.git/config to know about source.google.com, and to use an authentication helper that ties in to oauth (re-using the token that gcloud auth login will store locally) to authenticate. To limit deployment, make this the integration repo, and configure dev repos to push to it.
If you set up a separate staging version of the app, it's a policy decision on your side about whether to use the same scheme, or let developers deploy to staging individually. The mechanism you'd use to configure this is all .git/config wiring.