Kickstarting new projects

a conceptual proposal

All the steps
we need to do.

All the steps
we want to do.

Maintaining
project
infrastructure
over time

Topics I want to cover today

  • Kickstart development environment (excl. IDE)
  • Kickstart the project
  • Maintain IDE configuration
  • Keep the content in development context up to date
  • Maintain deployment configurations
  • Maintain development environment
    (and what you shouldn't do)
  • Maintain the project (and what you shouldn't do)

The main
idea behind
this concept

Initial thoughts

What I'd like to improve with this approach over Skeleton 🙈

  • Separation of concerns
  • Make different tasks accessible individually
  • Improve documentation by using dedicated tools that are already well documented
  • Provide useful tools without obligations
  • Decrease custom code and business logic for IaC, CI, CD as much as possible
  • Make it easy to break the rules, if you know them!

do opt-in, not opt-out

Tools I will cover today

The list is not final and may be subject to change

Ansible
Bash
Composer
DDEV
Docker Compose
GitLab CI
GitHub Actions
NPM
Taskfile
TYPO3 Surf
BookStack

as a base

Orchestrate multiple
containers with one
configuration

Handle multiple
containers with one
command

Also known as Taskfile

A modern, YAML-based alternative to makefiles

Even though GNU make is mostly known for (re)compiling purposes, both tools can be seen as task runners that can process various tasks

Tools and topics I will NOT cover today  (in detail)

PHP CS
PHPStan
PHPUnit
Renovate Bot
Prometheus
Icinga
kubernetes
Dots

Choose the right tool for the job

All the different tasks that need to be done

Incremental tasks

Incremental tasks (on demand)

  • Update user-generated-content and local database
          (TBD: load from backups)
  • Maintain IDE configuration
          (optional, maybe rekickstarting should be preferred, more on that later)
  • Automated tests
          (on demand, on push, TBD: pre-commit hook)
  • Run frontend build chain
          (automatically e.g. on deployment, on demand, watch task)

Incremental tasks (periodically)

  • Update potential hosts
          (remote hosts only)
  • Automated tests
          (local? on CI? TBD)

Incremental tasks
(on local environment during development)

  • Composer Auth available in container
          (make auth.json available in corresponding containers)
  • SSH access and other tokens
          (allow containers to access GitLab, GitHub, ...
           TBD: if access on production machine is still needed)

Kickstart stuff

Tasks that are only intended to run once

Kickstart things

The list is not guaranteed to be complete

  • Setup Docker  (docker compose for dev and potentially prod environment)
  • TYPO3 base setup  (e.g. composer.json, base configuration, initial .gitignore)
  • Kickstart Sitepackage  (TBD: what is needed and how to implement)
  • Setup Frontend Buildchain  (TBD: what is needed and how to implement)
  • Migration tools  (Rector, Fractor, Symfony Recipes, ...)
  • Coding Standards  (Kickstart CGL, code-style and linting configuration files)
  • Deployment configuration  (GitLab CI pipeline and/or TYPO3 Surf)

Some more tasks later in this presentation

(TBD material 😉)

Why not update docker incrementally?

Stay as close to production as possible

An update of the local environment should always result from adjustments to the production environment

But the

Why not updating coding standards automatically

Time passing by
should never
break tests
that worked
before

Updating coding standards should always be a paid task

e.g. during a major update

Avoid code changes that don't help to solve the current task

ToDo annotations however are fine

Consider creating a ticket and reference
the issue ID in the commit message

Why not update the sitepackage?

The only secure code is no code

Let's pick only the stuff we need

What about creating tasks that can copy and/or generate often used code and files?

Rekickstarting

It's not an official term. I made that up. 😉

Let's make introducing current coding standards and best practices its own project

Let's show
some code

Low-hanging fruits

I already had a steep
learning curve with
GitLab and HZI

and I wanna share this knowledge!

Let's make all this tasks its own centralized project

Use a superior and cross-project task collection

Code name xstarter

Product name faktory?

Synchronize user-generated-content

Synchronize, compress
and anonymize
user-generated-content

  • Load from internal backups instead of production
  • Provide endpoint on backup server
  • Centralize business logic for UGC/DB provider
  • Decouple task and potential updates from project
  • Only simple task on project side needed
  • TBD how to implement on project side - probably Taskfile

Documentation

BookStack
all the way

  • Single point of truth
  • Easy access for everyone
  • Editable by everyone
  • Exportable in different formats out of the box
  • Idea: Using BookStack API to export
    markdown as README for GitLab?

Still open topics

How to maintain
CI/CD
configuration

All the .idea(s) belong to me

.phpstorm.meta.php
&
phpstorm.inspections.xml

PHPSTORM_META

Might conflict with TYPO3 plugin in the future

Gets more and more obsolete due to Symfony DI

Inline annotation would work everywhere

Wrapper methods can help to keep code clean

Wrapper methods might simplify updates in the future

To inspect or
not to inspect

Probably hard to find common ground for inspections

Different inspections don't make sense in a collaborative environment

A clean IDE for one person may become a blinking Christmas tree for another

composer.scripts.json

a counter-proposal

  • Decouple from composer
  • Generate project bin directory
  • Wrapping these commands gives more flexibility
  • E.g. run things in different containers when needed
  • TBD: Use Taskfile to create these wrapper files
  • Are there any composer dependencies I missed?

Last but not least...

  • Wrapper DDEV commands
  • What's needed?
  • deploy, frontendbuild, spider, xdebug-phpstorm
  • XDEBUG: I have tried unsuccessfully to understand the added value