All geek questions in one place

Use merge or redirects to support deployment branches

I have AWS, which means I cannot use environment variables to manage my production and intermediate deployments. Therefore, I am forced to use separate branches for deployment, and I wonder if there is a better approach to servicing them?

If I merge the changes in my production branch, the commit containing my production settings will be lost in the history of the branches, which makes it difficult to configure these parameters.

However, I read that you should not use rebase in this situation, as this will make it difficult to roll back changes.

+5
source share
4 answers

I also ran into many problems for implementing git in my last project. After too many searches, I found this blog, and this is a really good way to support the git forking model.

Successful git branching model. enter image description here The central repo has two main branches with infinite lifetime:

  • master
  • to develop

The main branch at the beginning should be familiar to every git user. In parallel with the leading branch, there is another branch called develop.

We believe that origin / master is the main branch where the HEAD source code always reflects a state of readiness for production.

We believe that origin / develop is the main branch, where the HEAD source code always reflects the state with the latest development changes for the next release. Some would call this an "integration branch." Here you can create any automatic nightly builds.

Supporting branches

The different types of branches that we can use are as follows:

  • function branches
  • Disable branches
  • Fixed branches

function branches : function branches (or sometimes called topic branches) are used to develop new functions for an upcoming or distant future version.

May depart from: development

Need to reunite: development

Branch naming convention: nothing but a wizard, development, release, or fix -

Disable branches . Disable support branches when preparing a new production version. They allow you to use the last minute point and cross ts.

May depart from: development

It is necessary to unite again: to develop and master

Branch naming convention: release - *

Fixed branches : patch branches are very similar to release branches, as they are also designed to prepare for a new production version, albeit unplanned. They arise from the need to act immediately in case of an undesirable state of a live version.

May depart from: master

It is necessary to unite again: to develop and master

Branch naming convention: fix - *

More information on this branching git model can be found on the blog. Commands used for the branching model are also listed on the blog. Check out the blog for more details. I have successfully implemented the branching model in my project with some changes from the model mentioned in the blog. git is a powerful and flexible tool, and this is just one way to use Git.

+4
source

You can install two settings files (one for dev and one for prod)

You can then go to the " elasticbeanstalk/hook " script to write the actual configuration file for you after " git aws.push ".

You can see an example of a similar problem in " How to get a proxy server that supports nginx-blade server, which will be automatically redirected from HTTP to HTTPS?, About a Node (this may not be your exact case), where the file is .ebextensions / config will write /opt/elasticbeanstalk/hooks/configdeploy/enact/myscript.sh .

This last script is a hook that can be triggered during deployment and can update the actual configuration file of your environment.

+3
source

In master set both settings files ( settings_master and settings_prod ) and the symbolic link settings -> settings_master . Now branch prod off master (or merge master into prod if it already exists), and in prod change only the symbolic link settings to point to settings_prod .

Commit this change to prod .

Now do the whole development on master , and until you change the symbolic link itself (changing any of the settings files in order), you can combine master in prod as often as you like, without affecting the purpose of settings . Your application should get the configuration from settings .

This will result in a commit history that looks like this:

 ... -o---o---o---o master \ \ \ ... --o-------o---o prod

The difference from master to prod after each merge of master into prod will always be accurate:

 --- a/settings +++ b/settings @@ -1 +1 @@ -settings_master \ No newline at end of file +settings_prod \ No newline at end of file
+2
source

There are several links below that provide some opinions on the methodologies and arguments why you should choose reinstallation or merging.

  • Merging is ideal for passing code to a shared branch between teams. Because Rebase overwrites the history of commits, the context of related commits (for example, branching traits) is lost as the commits become linear based on timestamps.
  • Rebase may be ideal for pulling code into your working branch before returning to the general branch. Linear results and historical change can lead to more successful merging of commits.

Cm:

+2
source

Source: https://habr.com/ru/post/1205878/

More articles:


All Articles