Whenever Chef runs on a node, a Convergence happens. There are 3 steps to a convergence. They can be a part of an automated workflow pipeline, or run manually.
Pre-convergance
Pre-convergance happens before Chef is run. It can be added using Chef Automate or Chef Workflow, it can be added manually, or using tools like Jenkins. This occurs before a node is configure, and is best practice to include a pre-convergence item before every Chef convergence. This step includes items such as lint tests. Lint tests run tools to analyze source code to identify stylistic problems, Food Critic is a tool for this when using Chef.
Convergence
Convergence occurs when Chef runs on the node. It tests whether or not the defined resources are in the desired state. If they aren’t, Chef will change them as necessary to put them in the desired state, using a test and repair method. For example, if your resource to be installed is the Apache web server, Chef will first check to see if it is in the desired state of configuration. If it’s not, Chef will ensure the resource is put into the desired state. In other words, it will install the package.
It is important to note that this occurs on the node itself. Providers do the work to enforce the desired configuration. They are what the resources map to on the node, for example, on a Red Hat machine, the package resource maps to a yum command, and an apt command on a Debian based machine.
Another important fact to remember is that Chef is idempotent. Idempotency is demonstrated by the fact that Chef can be run over and over again without modification to the configurations if the configurations are in place.
Post-Convergence
Post-Convergance, Chef will run tests and verify a node is in the desired state of configuration. These tests are known as Unit Testing.