New Campbell's Process Outlined

There have been some adjustments to the process for Campbell's content updates and development. There are now three total environments for the Foodservice websites (includes Canada). Dev, Stage and Production are the three environments.

The dev environment is used to test code that has been implemented until it is in a stable condition. This uses the “develop” branch in Bitbucket.

Stage is used as a stable environment for approvals, as it reflects the same configuration and technology as production. This uses the “stage” branch in Bitbucket.

And I think we all know what production is, which uses “master” as the branch in Bitbucket.

CONTENT

When you are making a content update, you may do this directly in the stage environment. The should be accessed from the Okta tile when logging in. Please note that these are setup as multi-sites, so you will need to access either the US or Canada site in each prospective environment when you get to “The Landing Zone”. This can be access in the top-left nav called “My Sites”.

When your content update has been made in stage, the change must be approved by our account team and the Campbell’s marketing team prior to making the same update in production. Please confirm that the update is reflected in production prior to marking anything complete in our system. Note: it may take about 10 min to show up due to caching.

BACKEND LINKS VS FRONTEND LINKS

This has been tripping us up recently, so I want to explain. When you access the admin from Okta, that is the backend link. When you provide a link to your update (regardless of content or development that has taken place), you must use the frontend link. Please see below for the frontend links to use when passing on to our internal team or the client for approvals. If you share the backend link, it can cause path issues and certain features not to work. Please do not share dev links with our account team or the client.

• Dev – dev.campbellsfoodservice.com
• Stage – stage.campbellsfoodservice.com
• Prod – www.campbellsfoodservice.com

DEVELOPMENT (stop reading if you’re not a developer)

1. Install php global on PC - https://www.sitepoint.com/how-to-install-php-on-windows/
2. Install composer - https://getcomposer.org/download/
   1. Make sure to run "composer" in the CMD to test if the installation was successful
3. Commit all your changes into your current branch
4. Go to the pfw-wp-campbells-food-service-composer repo
   1. switch to the branch you are deploying to:
      1. develop branch -> Develop environment
      2. stage branch -> Stage environment
      3. master branch -> Production environment
   2. copy the composer.lock file
5. Go to your current branch
6. Replace the composer.lock file
7. Open CMD and CD to the directory of the composer.lock file
8. Run "composer update"
   1. if it returns an error
      1. follow step 12
9. Commit all new changes
10. Make a PR to the appropriate branch on pfw-wp-campbells-food-service
    1. 1. Only PRs to the develop branch don't need an approval from Cheo
11. If there is a conflict with the composer.lock file
    1. 1. Message Cheo and he will fix it
12. If "composer update" gives an error:
    1. Go to pfw-wp-campbells-food-service
       1. Create a PR from your current branch to the deploy branch
          1. develop branch -> Develop environment
          2. stage branch -> Stage environment
          3. master branch -> Production environment
       2. If it the deploy branch is "develop", approve the PR
    2. b. go to last commit of the PR branch
    3. copy the hash at the end of URL
       1. example: https://bitbucket.org/campbellsoupco/pfw-wp-campbells-food-service/commits/dcf04ec7831049a41c2ac3c877df510f4ec9dc5d
       2. copy everything after commits/
       3. This is the commit hash
    4. Go to pfw-wp-campbells-food-service-composer repo
       1. Create a new branch from Master
       2. use the same branch name as your branch from the PR
    5. View source of the branch
       1. edit the composer.lock file
       2. replace the packages.source.reference value with the commit hash
       3. commit changes
    6. Create a PR from your dev branch to the server you want to deploy to
       1. 1. if there are conflicts,
             1. Message Cheo and he will manually fix it.

OLD PROCESS === OUTDATED

Since there are now three environments (plus our own local), the flow goes as follows.

1. Make the code update(s) (whether a small ticket request or a full project) in our local Marriner environment (http://campbellsus.marriner.com/)
2. Create a JIRA ticket for the small change or large project being done (Megan and/or I can do this)
3. Create a Bitbucket feature branch from the JIRA ticket for (I can do this and can show others with access)
4. Create a Pull Request (PR) and merge the commits to the “develop” branch to deploy the code to the dev site. For this environment, we are able to merge our own PRs
5. Test and confirm that everything is functioning properly
6. Use the code sniffer Campbell’s has provided to ensure the code is up to Campbell’s spec. Adjust/edit as needed
7. Create a PR to the stage environment and add Cheo as the reviewer. Cheo must review, approve and merge the code before it is available on the stage site.
8. Send the link for internal and client approval. The client approval must be put in the JIRA ticket so IT can see it is approved prior to any move to production
9. Create a PR to the master branch. Cheo must review, approve and merge the code before it is available on the production site. Note: they only deploy the master branch requests on Tuesdays and Thursdays, so be sure to schedule accordingly. If it is a large development effort, IT may require a security scan while in the stage environment to ensure the code is safe before they will deploy to production
10. Confirm the code is fully functional prior to updating the JIRA ticket to “done”.