Skip to content

Update deployment.rst #7319

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from
Closed
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion deployment.rst
Original file line number Diff line number Diff line change
Expand Up @@ -54,7 +54,8 @@ Using Source Control
If you're using source control (e.g. Git or SVN), you can simplify by having
your live installation also be a copy of your repository. When you're ready
to upgrade it is as simple as fetching the latest updates from your source
control system.
control system. A common approach for this in Git is, to tag your release and
check out the Git tag on deployment (see `Git Tagging`_).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jepster is tag checkout more common or popular than pull master branch? I think it depend on methodology. I met both approach and I can't say that one of them is much more popular.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dominikhajduk Checking out the master branch is safer. Since you can rollback more clear to a previous release tag in case of failure. Git tags are the standard in module releases in the Drupal project.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jepster

Checking out the master branch is safer. Since you can rollback more clear to a previous release tag in case of failure.

Exactly. That's why I have doubts if checkout tag instead of checkout master and just pull new version from origin should be proposed here. Of course we both agree that tag should be created anyway.


This makes updating your files *easier*, but you still need to worry about
manually taking other steps (see `Common Post-Deployment Tasks`_).
Expand Down Expand Up @@ -197,6 +198,7 @@ Don't forget that deploying your application also involves updating any dependen
(typically via Composer), migrating your database, clearing your cache and
other potential things like pushing assets to a CDN (see `Common Post-Deployment Tasks`_).

.. _`Git Tagging`: https://git-scm.com/book/en/v2/Git-Basics-Tagging
.. _`Capifony`: http://capifony.org/
.. _`Capistrano`: http://capistranorb.com/
.. _`sf2debpkg`: https://github.com/liip/sf2debpkg
Expand Down