madetech / productionisation Goto Github PK

There are a few examples:

• https://www.jetbrains.com/help/rider/Using_EditorConfig.html
• https://blog.markvincze.com/automated-portable-code-style-checking-in-net-core-projects/

Will be resolved by #9

• One click deploys
• Low probability of error in deployments
• Reproducible deployments
• Reproducible development environments
• Understand usage of software at a glance
• Ability to defer technology decisions
• Code is the documentation
• Code Reveals Intent not Details
• Shared understanding of the domain written as expressive code
• Evolutionary Architectures
• Ability to *scout without fear
• Almost impossible to break existing behaviour (semantically stable test suites)
• Fast-executing ability to check that existing behaviour is still working correctly
• Non-brittle testing of the behaviour of code that received data from external services
• Non-brittle testing of the behaviour of code that sends data to remote services
• Reduced churn of files/functions/modules/classes
• No Tech-Debt Epics
• Single tech ecosystem includes multiple independently deployable components
• Sustainable Pace

Currently what we have is a flat checklist. This is great for giving a general overall score, however it can mean it's hard to see iterative improvements.

There are also certain targets that are difficult to hit if you've not been trying to reach them from the start.

I propose introducing Levels, where we can define a baseline of "you must hit these ASAP", while being able to define extended requirements that are less critical to implement.

This will no doubt resolve into a similar situation to Core skills, where people get stickers.

Introduce a requirement to have a process defined (either manual or automated) for certificate renewal.

Also introduce a requirement to have notifications for when a certificate is going to expire (time periods TBD)

a recent discussion has taken place about how best to address enterprise customer concerns on policies relating to holding of customer data.

While this issue isn't going to target a full solution to this problem, there are some key points that I feel most projects should adhere to.
I fully expect this to turn into a sliding scale, where basic requirements are:

• per user access to services
• every developer has most rights for ease of use
• bastion service for accessing service ports on infrastructure

to super hardened, where requirements are:

• per user access to services, with enforced MFA (maybe all of "what you know", "what you have", "what you are")
• follow principle of least privilege
• auditable access to sensitive material

Preferred targets would be:

make development-seed-batch
make development-seed-full

Is this even feasible? For example WATG and Diners club, very tricky to just pull down 5 accounts/products from those sites to use for local development.

Found this one to be a tough nut to crack when working on GovWifi. The default logger isn't able to hold contexts (for tags), or have filters.

I've got a WIP PR for using SemanticLogger, however it's not pretty. This could result in us writing a package and recommending its use.

PR from old repo:

https://github.com/madetech/live-services-field-guide/pull/67

@cybojenix did you want to migrate this over so that you still 'own' the PR?

Would be beneficial to have explicit mention of APM.

This would be an ongoing score based on the current stable release of languages and frameworks, so that we can aim to keep on top of this to reduce technical debt of large upgrades later down the line.

We've just renewed some of our domains, however the process is currently rather adhoc.

Introduce a requirement to have a process defined (either manual or automated) for domain renewal.

Also introduce a requirement to have notifications for when a domain is about to expire expire (time periods TBD).

To give a tangible example, I'm currently using JetBrains Rider to evaluate a project. JetBrains Rider has built-in Linter (called Code Inspectors), Code Coverage (via plugin) and Profiling (Debugger).

My initial feeling is to say that that we should find tools to do separately for the sake of continuous delivery pipelines.

We've discussed this internally on our slack and there have been no definitive answers.

cc @StevenLeighton21 @robinlacey (please ping others who may be interested in this discussion)

feel free to edit this description directly. I'll add them into the description if a comment is added.

Please use this template for flagging them:

**<language>[/<framework>]**
- style: <linter>
- complexity: <linter>
- security: <linter>
- checker: <linter>

In the event of multiple, use sublists:

- checker:
  - <linter>
  - <linter>

ruby:

• style: Rubocop (style, complexity)

python

• style: black

shell

• complexity: shellcheck
• security: shellcheck
• checker: shellcheck

It's not always clear how to report tech related issues. Often times mental notes are taken, akin to "this code needs refactoring", or they're written in code review but without further action taken.
Going down these unstructured routes leads to these issues being forgotten.

I don't think we should define a process here, but give some suggestions for what can be done.
The easiest might be adding #TODO notes as and when these issues are found, and periodically takes some time to go scouting.
Another suggestion might be, for more dire situations, exposing a trello board with all the tech related issues, so it can be seemlessly mixed in with sprints.

Regardless of the approach, the aim is to make sure tech debt is always exposed

Aliases nearer the bottom

Many of our points can be fulfilled by completing one-shot tasks.
An example of this is Sentry.

You can set up a Sentry service, and have it notifying to places, however it doesn't mean that Sentry will get used.
We should look into setting standards for usage, ie "Sentry errors are triaged within 24 hours, resolved within 1 week".

This is not limited to Sentry

Often, CD pipelines are things that take a while to setup, and having these defined in code serves as good visibility on what happens when onboarding into a project, but also as a backup, rather than the pipeline configuration being full stored just in a service or system.

Favour a Jenkinsfile if using Jenkins.
If using Heroku, even though they have the pipeline feature, favour a CircleCI pipeline to deploy to Heroku as this provides far better visibility.

Since this is a non-code project, might I suggest CC Attribution Share Alike?

https://choosealicense.com/licenses/cc-by-sa-4.0/

Reference: Section 5.1.6

5.1.6 Manual step to flip between blue/green environment

Why not go fully automatic i.e. Heroku's pre-boot. CloudFoundry has plugins that also do this automatically.

Something along the lines of what Pingdom offers.

Would also like something that can monitor cron/background related jobs too where we have an expected schedule, and if that fails to register that is has run for X number of times, throw an alert.

big one might be rubocop rules

Database
Production database has:

• Automatic failover - Premium has built-in automatic failover https://devcenter.heroku.com/articles/heroku-postgres-ha
• Daily automatic backups - Continuous Protection kind covers this? https://devcenter.heroku.com/articles/heroku-postgres-data-safety-and-continuous-protection
• Transaction logs for PIT recovery - Heroku Postgres Rollback