The Perfect Neos Project Setup

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

Transcript

1. The Perfect Neos Project Setup
2. Karsten Dambekalns Karsten 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
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