9. Deployer configuration
Allow to deploy from your command line in one or few
command.
For deploy it use your SSH key, or you can config using any
key file.
9
14. Deployer and Pipelines
So basically for deploy in Pipelines
workflow we need just add few
commands for run deployer script.
14
15. Deployer and Pipelines
Problem: usually docker container does not contain SSH
key, with access to git repository.
Solve: container launch with pipelines has access to special
environment variables witch we can you for storing secured
and unsecured data.
15
17. Pipelines Env
Pipelines environment can not store multi-lines text. It can
store only one string.
So we need way to put keys in this variables.
Lets encode it to base64
17
23. Git Flow
When using version control in a team, it's crucial to agree on
a workflow. Git in particular allows to do lots of things in lots
of ways. However, if you don't use a common workflow in
your team, confusion is inevitable.
git-flow is by no means a replacement for Git. It's just a set of
scripts that combine standard Git commands in a clever way.
23
27. Branching Model
• master always and exclusively contains production code.
You don't work directly on the master branch but instead in
designated, separate feature branches (which we'll talk
about in a minute). Not committing directly to the master
branch is a common hygiene rule in many workflows.
• develop is the basis for any new development efforts you
make: when you start a new feature branch it will be based
on develop. Additionally, this branch also aggregates any
finished features, waiting to be integrated and deployed
via master.
27
31. Releases
Do you feel that your current code on the "develop" branch is
ripe for a new release? This should mean that it (a) contains
all the new features and fixes and (b) has been thoroughly
tested. If both (a) and (b) are true, you're ready to start a new
release.
Release branches are named using version numbers. In
addition to being an obvious choice, this naming scheme has
a a nice side-effect: git-flow can automatically tag the release
commit appropriately when we later finish the release.
31
32. Finish release
• git-flow pulls from the remote repository to make sure you are
up-to-date.
• the release content is merged back into both "master" and
"develop" (so that not only the production code is up-to-date,
but also new feature branches will be based off the latest
code).
• to easily identify and reference it later, the release commit is
tagged with the release's name.
• To clean up, the release branch is deleted and we're back on
“develop".
32
33. Finish release
After finish release you can push changes, and your
bitbucket pipelines config for master brunch can release
changes to production server.
33
34. git-flow doesn't add any
functionality on top of Git.
It's simply a set of scripts that
bundle Git commands into
workflows.
34