There are many ways to start a new Neos-based project and there is a multitude of tools involved. These slides introduce a "perfect" way to set up a Neos project. A recording of the presentation is available at https://youtu.be/hWJSK0pE1H0

1. The Perfect
Neos Project Setup

2. Karsten DambekalnsKarsten Dumbledore

4. The Perfect
Neos Project Setup

5. The Best
Neos Project Setup

6. A Good
Neos Project Setup

7. What I Consider A Good
Neos Project Setup

8. Disclaimer
The term "best practice" along with "perfect" is very misleading.
There is never the best solution, only a solution that is the best fit in
a given situation.
Keep your brain moving, question what you have and try something
new every now and then.
Take everything you are going to hear as something to think about,
never as a rule.
There is no silver bullet.

9. Project Management

10. Content First

11. Who do we want to reach?
What are their goals?
What do we need to make reaching those
goals possible?

12. Create customised
content types.
No more unstructured
blobs of text!

13. Adopt an agile
working mode

14. Some truths
Doing development in sprints is not SCRUM.
Kanban does not magically finish your project.
Not giving a fixed price (or even an estimate) to your
client might be hard.
But spending days or even weeks to come up with a
plan that will inevitably change anyway would be
waste.

15. Get your project
management right, so
you can focus on the
following things…

16. Development
“as such”

17. Know your docs:
manual, references,
API

18. flowframework RTD
Flow
Requirements, Installation, Configuration

19. Neos references RTD
Flow references
Neos references

20. neos.github.io

21. Know your options

22. Settings.yaml

23. Know your ecosystem

24. neos.io/download-and-extend/
packages.html
packagist.org

25. discuss
discuss.neos.io

26. Stay focused

27. Implement only what
you need.
Don't use a package
you only need 10% of.

28. An example is not
using Neos.NodeTypes

29. Write tests

31. Write useful tests

32. Do the dishes

35. Learn and understand

37. But… eventually you
must understand the
tools you use.

38. Think about Fusion.
It seems intimidating at first, then you
start to get the hang of it.
And think "Ah, that's how it works!”
Except it doesn’t.
And then things start to feel awkward.

39. Keep learning. Adopt new
things. Question your own
best practice.
Take the time, it's worth it.

40. Development
Environment

41. Tools

42. Developers being able to
chose their tools are happier.
Let me choose some
tools for you…

43. vi vs. emacs

44. IDE vs. Editor

45. Use an IDE

46. phpstorm screenshot

47. PhpStorm
by Jetbrains

48. Neos plugin
by Christian Vette
https://github.com/cvette/intellij-neos
Fluid plugin
by Stefan Galinski
https://www.sgalinski.de/typo3-produkte-webentwicklung/typo3-fluid-phpstorm-intellij/

49. ZSH

50. Oh-My-ZSH
and the
Flow Framework Helper

51. flow helper video

52. github.com/sandstorm/
oh-my-zsh-flow-plugin

53. VCS

55. Using a version control
system is not optional.

56. Technology

57. Use the newest
version of PHP

59. Stay up-to-date

60. An update a day, keeps
the downtime away

61. Check security
Consider using a service like Symfony Security
Monitoring or implement something using the
SensioLabs Security Checker or roave/security-
advisories.

62. Redis
for caching

63. Elasticsearch
You Know, for Search

64. PostgreSQL
Can roll back DDL

65. Technologies like these can add a lot of value to a project
and knowing them allows to apply them when needed.

66. Works on my machine

67. Running things locally
For ages all I had was a local setup
of Apache with mod_php and name-
based virtual hosting, combined
with dnsmasq.

68. Just clone any Flow-based project
into a directory and it's available
through the web server. 🙂

69. Must switch globally between PHP
versions if needed, every project
has the same environment (PHP
modules, settings, …), specific tools
a project needs would need to be
installed on my machine, … 🙁

71. With Docker every project can be
run in an environment that can
closely match the production
environment.

72. Docker Compose provides a way to
define the needed environment
using a simple YAML file.

75. docker-compose-
up.sh

76. github.com/neos/Neos.NeosIo
docker-compose.yml
docker-compose-up.sh
.env

77. Make yourself
comfortable.
It will make you more
productive.

78. Managing
Dependencies

79. Created with graph-composer

80. Composer

82. Composercat

83. composercat
screenshot

84. Semantic Versioning

85. semver checker

86. semver.mwl.be

87. Add composer.lock
to version control!

88. composer install
is different from
composer update

89. Keep things together

90. Dependency chain
vs.
loading order

93. Repository of
test/a
Repository of
test/b
Repository of
test/distribution
Need to commit in
three repositories
Must update
composer.lock after
every change to test/a
and test/b

94. Repository of
test/b
Repository of
test/distribution
and test/a
Need to commit in two
repositories; must
update composer.lock
after every change to
test/b

95. Repository of
test/distribution and
test/a and test/b
Need to commit in one
repositories
Must update composer.lock
only after changes to
dependencies in test/a or
test/b

96. • Use path repository for
composer
• Exclude source folder from IDE
• Ignore Packages in VCS
• Composer will “install” via
symbolic links
• Dependencies are resolved as
expected
• One repository to rule them all

97. monorepo manifest

98. composer create-project
neos/splash
This is still work
in progress, but
hopefully useable
soon…

99. Dependencies are not
a necessary evil,
but an important part
of your project

100. Managing
Configuration

101. Configuration
overrides

102. Application
context

103. Application contexts
(can) have a hierarchy

104. Development Staging Live
Development Production/Staging Production/Live

105. Development Production/Staging Production/Live

106. Development Production/Staging Production/Live

107. Development Production/Staging Production/Live

108. 😱

109. Define
FLOW_CONTEXT
on all servers

110. Configuration is code,
treat it accordingly

111. Hosting & Deployment

112. Automate deployment
Surf – Deployer

113. Automate automation
Jenkins – Travis CI – GitLab CI – Codeship – CircleCI

114. Hosting options

115. simple

116. simple
uberspace

117. managed

118. managed
proServer – all-inkl.com

119. complex

120. complex
Digital Ocean – Docker – Kubernetes

121. nightmare

122. You have a managed server, but the hoster is inflexible.
You must not change server settings yourself, but the
admin is in a meeting. No access to log files, but the
support sends the logs except the interesting line at the
end. SSH is possible, but permissions don’t match. You
need PHP 7, but are stuck at version 5.3, because of other
customers on the same server.
Every developer at some point in history

123. Hosting options

124. Flownative Beach
www.flownative.com/beach.html

125. Karsten Dambekalns
karsten@flownative.com
@kdambekalns
www.flownative.com
@flownative