jkniest / template-app Goto Github PK

Add Sensiolabs Security Checker & https://github.com/arminc/clair-scanner to circleci pipeline (only develop or something)

https://medium.com/@titasgailius/initial-laravel-setup-with-vuejs-vue-router-vuex-in-typescript-305f7fe9d62b

Install Drone CI on one primary server and build the drone configuration

Increase the hash method to argon2i instead of bcrypt

https://github.com/hirak/prestissimo

The new version of any release should completely be build inside the docker container on the pipeline. This has multiple advantages:

• The target server does not need git / access to the git repository
• Every release has the correct container, dependencies, etc.

The only big disadvantage is (because of zero downtime deployments and rollbacks):

• Every release must have it's own docker tag. It wouldn't be enough to have one production tag since when I am going to rollback to an old release the old docker containers should be used.

Some notes:

• The tag:production job must be modified to tag the branches like this: production-{{uniqueIdOfThisRelease}}
• Same for staging
• The mount of the volumes should be splitted in somekind of docker-compose-dev.yml so that it wouldn't be used inside the production environment
• In that case probably extract some bin/compose command which handles the loading of multiple compose files nice and easy

https://laravel.com/docs/5.6/dusk
https://github.com/beyondcode/dusk-dashboard

Evaluate https://github.com/php-pm/php-pm and add it to the docker setup

Build one image for each branch that is being build.. to get the normalized branch name see also:

https://circleci.com/docs/2.0/env-vars/#example-configuration-of-environment-variables

If all tests are successful re-tag the images with the staging tag. Also change master-Tag to production

• Using dynamic image tags (using bash_env)
• Modify the production.sh shell script to just "tag" / it should take a source branch and target branch as parameters
• Change the master-Tagging to production
• Only tag master-Images if the CIRCLE_BRANCH is master
• Add a job to tag staging Images if the target branch is develop

https://github.com/github/fetch

Realisieren von Zero-Downtime Deployments im Stile von Envoyer, etc.

Dabei schauen, ob und wie man das mit der DB lösen kann

Add docker healthchecks scripts to each service which doesn't support this by default

The phpunit testing suite shouldn't use a dedacted postgres_testing service. Instead a simple new database template_testing should be created and used.

We should support basic auth in the .env file. So for example, we could do something like:

NGINX_BASIC_AUTH_USER=staging
NGINX_BASIC_AUTH_PASSWORD=secret

Only then the basic auth should be enabled on traefik

Update to PHP 7.4 in the docker containers (if laravel and the packages supports it yet).

Add a staging deployment to the circleci pipeline as a template for new projects.

Currently we need to do some manual steps to deploy. We must make an initial git clone and copy the .env file. In the best case all of this should happen completly automatically and we can run the deployment on a new server without doing some extra work.

Deployments are currently marked as "passed" if something via ssh went wrong.

Remove the traefik-data volume from the docker-compose file

Update von Inertia:

https://github.com/inertiajs/inertia/releases/tag/v0.1.0

Install laravel ignition

Run a circleci job simutanely to the build job which cleans up the registry itself using:

• https://docs.gitlab.com/ee/api/container_registry.html#delete-repository-tags-in-bulk

Rules should probably be:

• name_regex -> should match 376279b6-1f96-4114-b61c-688346b99a34
• older_than -> 1d

If a production build is made, automatically tag the current image as "production" or "master" and push it back to the registry.

Also make IMAGE_TAG dynamic (in .env) for the compose file. So the production environment can load the images with the production tag and the staging / local development can load "develop".