Aprender CoB

# cob-cli deploy command

cob-cli deploy [-f,--force, --servername <servername>]

cob-cli deploy is used to deploy your finished development onto the server. It's used as the final stage of a typical cob-cli workflow, which generally ends in the deployment of tested and ready-for-production changes.

# Execution Details

Similar to cob-cli test, a sequence of essential consistency checks must be performed before cob-cli allows the cob-cli deploycommand to be run.

# Consistency Checks

Remember: cob-cli aims to help coordinate and organize work. So, before actually deploying our changes, cob-cli will go over the following consistency verifications to avoid unwanted changes/modifications:

Start deployment…
Checking conditions to deploy <branch> to <server_name>.cultofbits.com
   Check connectivity and permissions
	 Check git status
   Check there's no 'cob-cli test' running on server
   find out branch-for-HEAD
   find out SHA for last-deploy on specified server
   git checkout SHA-for-last-deploy
   Apply last enviroment specifics
   Check last-deploy == serverLive
   Undo last enviroment specifics
   git checkout branch-for-HEAD

  1. Check connectivy and permissions It starts by verifying if the user has permission to connect to the server itself.

  2. Check git status For the final check, cob-cli updateFromServer will ascertain if the user has a clean working tree/local repository. In other words, it checks if the user is either 1) behind the origin of the current branch 2) has uncomitted or unstashed changes.

  3. Check there's no 'cob-cli test' running on server Since other users may be running tests in the same server we are working on, there may be other (temporary) files that we do not want to copy over to our machine. To avoid this, it verifies if there are tests running. If it detects tests, the command is aborted.

  4. find out branch-for-HEAD cob-cli checks in which branch you are currently operating.

  5. find out SHA for last-deploy on specified server Every CoB server contains a file in /opt/others/cob-cli/lastDeploySha. It contains the signature (SHA) of the git commit used for the last deploy. In this step, cob-cli will fetch this SHA.

  6. git checkout SHA for last-deploy Your local repository will be checked out to the SHA used in the server's last deploy (fetched in step 4). This means your local files will be changed to match the server's files when it was last deployed.

  7. Apply last enviroment specifics Each CoB server might have multiple (previously configured) environments associated to it, such as 'production' or 'quality'. These environments allow for specific files to be copied only to them. If you want a file important.txt to be only available in the 'production' environment, you'd alter the name to important.ENV__production__.txt. In this step, files with the discriminated environment names that match the environment being tested against, are temporarily renamed to their correct name (in this case, it would become important.txt) and files corresponding to other environments are (temporarily) removed and/or ignored.

  8. Check last-deploy == serverLive When reaching this step, it will check if the server content is the same as to when it was last deployed. It does this by comparing the server's current files to the ones now in the local machine. If this step fails (and warns the users), it means that an unauthorized change was made to the server's content - meaning someone could've altered the server directly or without using cob-cli. To avoid losing previous work, cob-cli aborts at this step if it finds unexpected changes. You can check our Troubleshooting page (opens new window) for more information on this type of failures, possible solutions and ways to avoid/mitigate such issues.

  9. Undo last enviroment specifics After the comparison in the previous step, cob-cli will now re-add the environment prefixes to your local files to match the reality: important.txt -> important.ENV__production__.txt

  10. git checkout branch-for-HEAD Now that cob-cli has confirmed that everything is OK with both yours and the server's contents, it returns to the branch in which the local repository was when the process started.

# Deployment Execution

Posterior to the verifications, cob-cli gets a 'green light' to perform the actual deployment, which is decomposed into the following steps:

Register release in DEPLOYLOG.md
git push (branch: <branch_name>)
Apply new enviroment specifics
Deploy files to server's live directories
Set last environment deployed
Undo new enviroment specifics
  1. Register release in DEPLOYLOG.md Logs the deployment in DEPLOYLOG.md. 2.git push (branch: <branch_name>) Pushes your commited changes to the deploy branch. 3.Apply new enviroment specifics Each CoB server might have multiple (previously configured) environments associated to it, such as 'production' or 'quality'. these environments allow for specific files to be copied only to them. If you want a file important.txt to be only available in the 'production' environment, you'd alter the name to important.ENV__production__.txt. In this step, files with the discriminated environment names that match the environment being tested against, are temporarily renamed to their correct name (in this case, it would become important.txt) and files corresponding to other environments are (temporarily) removed and/or ignored. 4.Deploy files to server's live directories Copies the to-be-deployed files into the CoB server. 5.Set last environment deployed Logs the last deployed environment in the CoB machine. 6.Undo new enviroment specifics As a final step, cob-cli will now undo Step 3 and re-add the environment prefixes to your local files to match the reality: important.txt -> important.ENV__production__.txt

# Options

-f --force
Skips all consistency checks, and deploys the content.

--servername <servername>
Name of the CoB server to deploy to. Default: server specified in prod environment. This may be combined with -e to push environment specific files to a server different than the one specified in the environment.

-e --environment <env_name>
Name of the target environment.

-V --verbose
Verbose execution of tasks

# -f --force option

The --force option allows to bypass the consistency checks (the conflict tests) and deploy the local configuration independently of existing conditions, ongoing tests, etc.

WARNING

This flag/option should be used with EXTREME CAUTION, AND SHOULD ONLY BE USED AS A LAST-RESORT for problems that have no other solution.

This option also might not be available to the whole dev team

← customize command →