This document discusses using Bitbucket Pipelines and Deployer to deploy code from a Bitbucket repository. It recommends using Deployer, a simple PHP deployment tool, configured through Pipelines environment variables to deploy from the command line. The document also recommends using Git Flow and git-flow scripts to manage features, releases and branching through a common workflow. Feature branches are merged into develop and releases are merged from develop into master and deployed through Pipelines.

1. Deploy with BitBucket
Pipelines and Deployer
Boiko Dmytro

2. Bitbucket Pipelines
Build, test and deploy from Bitbucket
2

3. Build and Test
3

4. Build and Test
4

5. Build and Test
5

6. What we need to deploy with
Pipelines?
• Pipelines
• Deployer
6

7. Deployer
Deployer - fast and simple deployment
tool for PHP.
7

8. Deployer configuration
8

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

10. 10

11. 11

12. 12

13. 13

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

16. 16

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

18. Pipelines Env
18

19. Pipelines deployer
19

20. 20

21. 21

22. 22

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

24. Git flow
24

25. 25

26. 26

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

28. Branching Model
28

29. 29

30. Finish feature
• Finish with git flow
• Finish with merge request
30

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

35. Thanks!
Any questions?