Stephan van Hulst wrote:
The only thing I can tell you for sure is that the pipeline first builds, then deploys.
Stephan van Hulst wrote:
Testing the software can be done as part of the build by the build tool, or it can be a separate step in the CI pipeline, or it can even be done at the very end after the software has been deployed, or any combination of the above. It completely depends on the team philosophy and on the project requirements.
Tim Holloway wrote:
Jenkins can do a lot of its magic directly, but it also leverages the tools it controls. For example, if a Maven build includes the "test" goal, that's what causes the tests to be run using the test runner Maven plugin and can cause them to be summarized and reported via the surefire-reports plugin.
Mike Simmons wrote:It means to pay attention (attend) to vocal modulations, how speaker's voices change as they talk, changes in pitch, volume, speed, and possibly other things.
Stephan van Hulst wrote:No, because it's common courtesy not to waste your colleagues' time with a pull request that contains merge conflicts from the very instant it was created.
Be courteous, and fix merge conflicts before you create the pull request.
Stephan van Hulst wrote:No, because it's common courtesy not to waste your colleagues' time with a pull request that contains merge conflicts from the very instant it was created.
Be courteous, and fix merge conflicts before you create the pull request.
Tim Holloway wrote:
And of course, do so judiciously. Overdo it and people won't take you seriously.
Tim Holloway wrote:
So you first must attend to normal modulations,
Les Morgan wrote:
A good speaker knows how and when to emphasis using slight tonal modulation of their voice, or slight volume changes. Think of a good speaker, one you enjoy listening too. listen for how they emphasize and contrast things using voice inflections.
nobody likes to listen to a monotone presentation, but no body like to listen to a person that is inappropriately using voice inflections or volume in their voice either.
Les
Stephan van Hulst wrote:
When the feature is done, pull the target branch. This should NEVER lead to merge conflicts.
Merge the target branch into your feature branch locally.
Merging the target branch into the feature branch may lead to merge conflicts. Resolve these.
Stephan van Hulst wrote:Jenkins is NOT a tool that takes care of CI/CD completely. It's a tool that manages the CI/CD pipeline. It delegates to other tools for the specifics of CI or CD.
Stephan van Hulst wrote:
Depending on your requirements, CodeDeploy is an example of a tool you can use to deploy your application