Skip to content

Commit 0b50277

Browse files
committed
Add SeQura repositor templates files
1 parent a76fdd1 commit 0b50277

File tree

7 files changed

+217
-0
lines changed

7 files changed

+217
-0
lines changed

.github/CODEOWNERS

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,2 @@
1+
* @sequra/integrations
2+

.github/PULL_REQUEST_TEMPLATE.md

Lines changed: 54 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,54 @@
1+
✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂
2+
✂✂✂ REMOVE FROM THIS PART BEFORE SUBMITTING YOUR PULL REQUEST ✂✂✂
3+
✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂
4+
5+
Here are some friendly reminders before submitting your pull request:
6+
7+
- There should be an issue describing the motivation for this change.
8+
- Everything should be well tested.
9+
- Check that you are not making any intensive/slow queries (provide db explain if necessary).
10+
- Migrations should be safe https://sequra.atlassian.net/wiki/display/EN/Safe+Operations+For+High+Volume+PostgreSQL
11+
12+
YOU CAN REMOVE THE PARTS OF THE TEMPLATE THAT DO NOT APPLY TO YOUR PULL REQUEST
13+
14+
✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂
15+
✂✂✂ REMOVE UP TO THIS PART BEFORE SUBMITTING YOUR PULL REQUEST ✂✂✂
16+
✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂
17+
18+
### What is the goal?
19+
20+
_Provide a description of the overall goal (you can usually use the one from the issue)_
21+
22+
### References
23+
24+
* **Issue:** _jira issue goes here, if suggesting a new feature or change, please discuss it in an issue first_
25+
* **Related pull-requests:** _list of related pull-requests (comma-separated): #1, #2_
26+
* **Honeybadger errors:** _list of links to Honeybadger errors (comma-separated): link1, link2_
27+
* **Any other references (AppSignal, Prometheus, ...):** _list of links to other references (comma-separated): link1, link2_
28+
29+
### How is it being implemented?
30+
31+
_Provide a description of the implementation_
32+
33+
### Opportunistic refactorings
34+
35+
_Have you improved the code/app in anyway? Explain what you did._
36+
37+
### Caveats
38+
39+
_If you find any, please describe all the special conditions._
40+
41+
### How is it tested?
42+
43+
_Automatic tests? Manual tests?_
44+
45+
_If it cannot be tested explain why._
46+
47+
_Add use cases if specs are incomplete or missing._
48+
49+
### How is it going to be deployed?
50+
51+
_If it does not require anything special, just write "Standard deployment". Otherwise, put the required steps._
52+
53+
- [ ] _Step 1_
54+
- [ ] _Step 2_

README.md

Lines changed: 28 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,28 @@
1+
# PHP-Client
2+
3+
This is a simple composer package to provide SeQura's API client.
4+
5+
## 📖 Overview 📖
6+
> The Sequra\PhpClient\Client class provides a simple interface to interact with the Sequra API.
7+
The Sequra\PhpClient\BuilderAbstract class provides a base class to build the order payload that the Sequra Order API expects. It could be extended to map the platform order information to the Sequra order payload.
8+
9+
### ⚙️ Components summary ⚙️
10+
> N/A
11+
12+
### 📊 Observability and dashboards 📊
13+
> N/A
14+
15+
### 🔌 System dependencies 🔌
16+
> Usable in PHP developments or platforms based on PHP
17+
18+
## 👩‍💻 Development environment instructions 👩‍💻
19+
> N/A
20+
21+
### 🚧 How to run the test suite 🚧
22+
> TBD
23+
24+
## 🚀 Install instructions 🚀
25+
> `composer require sequra/php-client`
26+
27+
## URLs list
28+
N/A
Lines changed: 19 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,19 @@
1+
# Record architecture decisions
2+
3+
Date: 2019-06-05
4+
5+
## Status
6+
7+
Accepted
8+
9+
## Context
10+
11+
We need to record the architectural decisions made on this project.
12+
13+
## Decision
14+
15+
We will use Architecture Decision Records, as [described by Michael Nygard](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions).
16+
17+
## Consequences
18+
19+
See Michael Nygard's article, linked above. For a lightweight ADR toolset, see Nat Pryce's [adr-tools](https://github.com/npryce/adr-tools).

docs/decisions/README.md

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
# Architectural design records
2+
3+
The idea is to provide a basic integrated ADR generation for Timon
4+
- You can see an [index of ADRs here](./index.md)
5+
- You can see the [base template here](./template.md)

docs/decisions/index.md

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
# Architectural Decision Log
2+
3+
This log lists the architectural decisions for [project name].
4+
5+
* [Record architecture decisions](2019-06-05-record-architecture-decisions.md)
6+
7+
For new ADRs, please use [template.md](template.md) as basis.

docs/decisions/template.md

Lines changed: 102 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,102 @@
1+
✂✂✂✂✂< REMOVE FROM THIS PART BEFORE SUBMITTING YOUR ADR ✂✂✂✂✂
2+
# ⚠️ Should this be an ADR?
3+
Are you in doubt if this document you or your team propose needs to be an Architectural Decision Record?
4+
5+
Let's check it through several questions 😊
6+
7+
Starting with a `stop question`:
8+
9+
❓ Is this ADR related to a change in this specific application or service?
10+
**If** the answer **is "no"**, which means that this ADR affects this application and others, **end this document here** and start writing a general Decision Record [here](https://sequra.atlassian.net/wiki/spaces/EN/pages/3771039771/Tech+Decision+Records#List-of-Tech-Decision-Records)
11+
👇 **If** the previous **answer is a "yes"**
12+
13+
Let's **continue** with these other questions:
14+
15+
❓ Will this ADR provoke a breaking changes or sensible modifications inside this application or services' engine, interfaces, APIs or [seams](https://archive.org/details/working-effectively-with-legacy-code/page/n51/mode/2up) `(look into chapter 4 of this book for the reference)` between domains?
16+
❓ Will this ADR introduce new architectural or software design patterns in the project (f.ex: big refactors which provide that an old feature can work in a new way, introducing a new technology/gem/package/etc ...)
17+
❓ Will this ADR impact other teams’ roadmaps or velocities meaningfully?
18+
❓ Does this ADR imply different approaches/options for which you want/need the opinion of the rest of the team?
19+
❓ Does this ADR modify/impact another existing or very similar ADR (superseeding or refining it)?
20+
21+
Then, evaluate your answers:
22+
23+
👉 If you checked any of those boxes, this topic does need an ADR.
24+
👉 If you didn’t check any of those boxes, doing an ADR is optional.
25+
26+
**❗ Depending on your decision, either delete this section or delete this document!**
27+
28+
✂✂✂✂✂< REMOVE FROM THIS PART BEFORE SUBMITTING YOUR ADR ✂✂✂✂✂
29+
30+
# [short title of solved problem and solution]
31+
32+
---
33+
* **Status:** [🚧🌱 wip | 💡 proposed | 🚫 rejected | ✅ accepted | 🕸 deprecated | … | ⬆️🌱 superseded by [ADR-0005](0005-example.md)] <!-- optional -->
34+
* **Deciders:** [list everyone involved in the decision] <!-- optional -->
35+
* **Proposal date:** [YYYY-MM-DD when the decision was proposed] <!-- optional -->
36+
* **Due date:** [YYYY-MM-DD when the decision is finally made] <!-- optional -->
37+
* **Technical Story:** [description | ticket/issue URL] <!-- optional -->
38+
---
39+
## Context and Problem Statement
40+
41+
[Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.]
42+
43+
## Decision Drivers <!-- optional -->
44+
45+
* [driver 1, e.g., a force, facing concern, …]
46+
* [driver 2, e.g., a force, facing concern, …]
47+
*<!-- numbers of drivers can vary -->
48+
49+
## Considered Options
50+
51+
* [option 1]
52+
* [option 2]
53+
* [option 3]
54+
*<!-- numbers of options can vary -->
55+
56+
## Decision Outcome
57+
58+
Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)].
59+
60+
### Positive Consequences <!-- optional -->
61+
62+
* [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …]
63+
*
64+
65+
### Negative Consequences <!-- optional -->
66+
67+
* [e.g., compromising quality attribute, follow-up decisions required, …]
68+
*
69+
70+
## Pros and Cons of the Options <!-- optional -->
71+
72+
### [option 1]
73+
74+
[example | description | pointer to more information | …] <!-- optional -->
75+
76+
* Good, because [argument a]
77+
* Good, because [argument b]
78+
* Bad, because [argument c]
79+
*<!-- numbers of pros and cons can vary -->
80+
81+
### [option 2]
82+
83+
[example | description | pointer to more information | …] <!-- optional -->
84+
85+
* Good, because [argument a]
86+
* Good, because [argument b]
87+
* Bad, because [argument c]
88+
*<!-- numbers of pros and cons can vary -->
89+
90+
### [option 3]
91+
92+
[example | description | pointer to more information | …] <!-- optional -->
93+
94+
* Good, because [argument a]
95+
* Good, because [argument b]
96+
* Bad, because [argument c]
97+
*<!-- numbers of pros and cons can vary -->
98+
99+
## Links <!-- optional -->
100+
101+
* [Link type] [Link to ADR] <!-- example: Refined by [ADR-0005](0005-example.md) -->
102+
*<!-- numbers of links can vary -->

0 commit comments

Comments
 (0)