Some Words from Todd on Merge Deploy Processes.

Unknown
Unknown
in Support Agents

First off. The term "deploy" to us means to deploy the code in production. It seems like when they say "deploy" they mean "merge". Vanilla deploys the master branch to production, the stage branch to stage, and sometimes a develop branch to development. When you merge a branch to master you are telling us that the next time we deploy then you want that code to go to production. If you are not ready for a branch to go to production then I wouldn't ask for it to be deployed to master.

I would think they should a) make all changes they want as PRs against stage. b) deploy to stage and test. c) when ready, make a PR to merge stage into master d) we approve the pr and merge to master e) us or them deploy that master to production.

If they want a merge into master, but not have the code deployed they can tell us not to deploy. They can then deploy when they wish using VIP deploy. If they see a problem then create a ticket telling us to roll back and we will. It's okay if there is a problem, but I would say they should have a decent amount of confidence that the code is ready to deploy to production.

The theme sitting in the master branch, but not getting deployed is fine, but that increases the likelihood that someone forgets and deploys that code. Code should generally be merged into master when it is very close to being ready to deploy.

This might also be useful: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/reverting-a-pull-request.

Reverting a pull request - GitHub Docs

You can revert a pull request after it's been merged to the upstream branch.

The unwritten thing here is I'm hesitant to "detail exactly what the customer should do in Github" because we don't want to be responsible for people learning git.

Comments

  • Unknown
    Unknown

    Notes from Todd to Bitdefender on how to use Gits

    1. Vanilla’s deploy always just points at a branch. Production points to master, stage points to stage, and develop points to develop.
    2. When doing a VIP deploy Vanilla will pull your repo so that it is up to date for the branch.
    3. We ideally want to see a development practice where all three branches start out in sync. Then we merge develop into stage and then stage into master. When we see a PR for stage we should just see it coming from develop. When we see a PR for master we should just see it coming from stage.


    That’s how our customer repos are deployed. Everything else is just an understanding of git, such as:

    1. You can check yourself what will be deployed by looking at the code in your repo on the various branches. You can do this by browsing Github or on your localhost.
    2. There are a wide variety of git GUI tools out there that let you browse branches so you can see what your code looked like at a point in time and what the commit hashes are. If you make good commit messages this will also help you remember what you did.
    3. A git GUI will also help you with commits. Most of our developers make sure they review their code before committing. This ensures that stray files or partial changes don’t get committed.
    4. If you make a mistake and want to revert some changes or set one branch to look like another branch then there are various ways to do this in git. I recommend reading up on some articles such as this:
    5. Resetting, Checking Out & Reverting | Atlassian Git Tutorial.
    6. In your case, I think learning how to make a PR based on a soft reset is probably going to help you.


    It is difficult for us to give you exact git instructions on what to do because your questions aren’t 100% clear based on git and our view of your repo. Our devs won’t know what you mean when you say “old theme” or “new theme”. Is that a theme you copied? Is that a theme from a day ago? A month ago? You know what your old theme is, but our devs just look at PRs as they come in. Giving you exact git commands to enter is going to lead to problems if you don’t know what they do.


    I strongly recommend some reading or tutorials on how git works. There are other source control systems out there, but git is the industry best practice and you are unlikely to escape it in your career.

  • Unknown
    Unknown

    Hidden

    If you navigate to a client's theme in github, you'll see an addon.json file. Clicking on that will show some information about the theme. This is specifically about the 'Hidden' parameter.

    image.png

    For client themes, this hidden line should NOT appear at all.

    If hidden is set to false, then that theme will show up for every site on that theme's cluster.

    If hidden is set to true, then that theme will appear invisible (not show up in theme settings).

Categories