Technologies

At this stage, we work with the Client's IT department: developing exchange APIs, designing data exchange channels. The result is a one-way or two-way exchange with ERP, AXAPTA, SAP, and over 20 other lesser-known accounting and automation systems.

We will set up a CRM for you (AMOCrm, or RetailCRM), after which you will have detailed sales reports, segmentation by different client types for SMS and email campaigns, and profitability analytics by advertising source and product/service type.

We have our own DevOps engineers: we'll build an optimal deployment scheme, configure a cluster, conduct load testing, and ensure 24/7 monitoring after the project launch.

Task Evaluation Rule

• Always provide estimates for tasks

• If a task already has an estimate from another developer, re-estimate if you disagree with it

If you're working on a task with someone else's estimate, you're agreeing with it.

Project Development Rules

• Development is done strictly in our gitlab

• Commit and push daily work results to the repository every day. There should be no situations where you lose several days' worth of work due to reasons like 'the computer broke,' 'I was moving and forgot to copy,' etc.

• Submit merge requests to your team lead or senior frontend developer for review.

Project Quality Requirements

General Requirements

Chrome, Firefox, Safari, Edge

The exact browser versions, as well as additional versions, should be requested from the manager before performing the task if they are not specified in the technical specification.

By default, support for the last two versions of browsers should be ensured.

The site should be responsive

• Logos should be in SVG format

• On production and test environments: Regular images should have webp versions, and their size should be appropriate for the container (picture tag)

• All links should respond to :hover, :active, and :focus

• When creating static pages (e.g., News details), the majority of static elements should be styled. Example: links, ul/ol lists, tables, headings.

• When creating static pages, images should not be forcibly stretched to full width. Add styles to img: max-width: 100%, display: block, margin: 0 auto, padding: 10px, so images retain their natural size but do not exceed the size of the static page container.

• Textarea resize should not break the layout

• The footer should 'stick' to the bottom of the browser when there is no content or only a small amount of content

• Slider pagination should not break when there are many slides. It should move or go to the side. Ask the manager and designer how it should be for the current project

• Form validation should work

• The phone field should use a mask

• The form 'submit' button should be disabled on the first click to avoid multiple submissions. It should be re-enabled after receiving a response from the server.

• Display a message about successful/unsuccessful form submission

• All interface elements that update their data without reloading the page should have a preloader

• All lists (Requests, users, etc.) should have pagination. If it's an SPA, the API should provide data considering pagination

• When creating a live filter (a filter working without pressing the apply button), use request interruption

• Information on project assembly and complex functionality should be described in the README.md file of the project

• Create a pop-up on the site if cookies are disabled in the client's browser. This can be checked with JS through navigator.cookieEnabled. The message in the pop-up should say, 'To ensure the site works correctly, cookies need to be enabled in the browser.'

• Code should be written according to the project's ESLint configuration

• Code should be modular. Module names should reflect the content's meaning

• Libraries are installed via yarn

• Use swiper for creating sliders

• If the project works with an API, domain addresses should be placed in environment variables. The .env file.

• The .env file should not be under git

• Create a .env.example file listing the required environment variables. Variables should have a description

• Form submission should work via FormData

• BEM

• Code should be modular. Module names should reflect the content's meaning

Additional Requirements for SPA Projects

• Product catalog filter settings should be displayed in the URL with GET parameters

Additional Requirements for Static Markup

• Markup must pass W3C validation

• Semantic markup. At a minimum, titles, descriptions, and h1 headings.

• Images must have alt attributes

• Attribute names and values (class="detail-page", id="news-list", etc.) should be in kebab-case style

 

1. Before Starting Work

We work strictly with GIT. No work is done without GIT.

2. GIT Setup Requirements

The stage branch must be enabled on the main host. The master branch is only used for the production host.
Use only \n for line breaks.
Ensure .gitignore is correctly configured.
Example of .gitignore setup:

/upload/
/upload
/local/vendor/
/local/vendor
/web.config
/.htaccess
/robots.txt
/*.xml
*.swp
*.log
*.zip
*.tar
*.rar
*.gz

If the entire folder is placed in .gitignore, but a specific template needs to be worked on, it can be returned to git using: !templates/learning_10_0_0/
.gitignore can be modified and expanded depending on the project's needs.
Debugging scripts, logs, media files registered in the database, and other such files should not be included in GIT.
All developments are reviewed by the team lead/senior project programmer. Clarify the main programmer with the manager. A developer does not change the master, stage, layout-master, layout-stage branches, or branches created by other developers, bypassing the team lead. 1 developer - 1 host. If several developers should work simultaneously on the project, the number of hosts on the project should be equal to the number of developers + 1 (a common host where all changes are merged). The project manager monitors this and should be informed if the requirement is not met.
All developer developments are first merged into stage, then into master. Nothing is merged directly into master. All new branches for new tasks start from the current stage. The delivery of changes to production is handled by the project team lead or their senior project programmer.

3. Transferring Developments and Deployments

3.1. Mandatory merge of all developments into the repository on Tue and Thu

Every Tuesday and Thursday, all developments must be merged into the remote repository. Developments are merged as they are ready and mandatorily on Tue and Thu, even if the block is not finished. The responsible party for control is the Team Lead. The executor of this event is the developer. The developer must push all developments to the repository by 7:00 PM on Tuesday and Thursday. The team lead, depending on the project's needs, can change the frequency of mandatory merges into the repository. It can be done more often, but not less. If there are no additional requirements from the team lead, mandatory merges into the repository are on Tuesday and Thursday. A penalty will be imposed for violating this requirement. If there was continuous downtime between merge deadlines, this requirement does not apply.

3.2. Production Deploys

Deployment days - Mon, Tue, Wed, Thu from 10:00 AM to 4:00 PM. Fri from 10:00 AM to 3:00 PM. Exceptions are possible only for urgent tasks and by agreement with the project manager.

4. Creating and Updating a New Branch Before Starting a New Task

Branch naming rules are described in section 6. Update the local stage branch from the remote repository. Create a local development branch from stage.

5. Report on Work Done and Preparation for Moving Developments to Pre-production for Verification

After completing developments, you need to perform a git pull ... into the current branch from the stage branch of the remote main repository to prevent conflicts.
Push the branch with developments using git push ... into the same branch of the remote repository.
In the remote repository, create a merge request into stage to the team lead or senior on the project if they are responsible for merges.
Attach in the checklist item or in the task comment, if there isn't one, a link to the merge request with the development and a comment on what the development is.
Notify the team lead or senior on the project, if they are responsible for merges, to review the work and accept the merge request or send it back for revisions.
If everything is okay, review the work on the main test environment.
Testing of developments is conducted only on the main test environment!
Note: At the project team lead's discretion, the branch update may be done from the master branch instead of stage.

6. Rules for Moving Developments to Production

If the completed task needs to be moved to production:
You need to perform a git pull ... from the master branch of the remote main repository to prevent conflicts.
Create a new merge request, but this time merging into master.
Attach in the checklist item or in the task comment, if there isn't one, a link to the merge request with the development and a comment on what the development is.
Also, notify the team lead or senior on the project, if they are responsible for merges, who will review, accept the changes (team lead and manager), and pull the changes into production.
Verify functionality on production.
For proper transfer, it's important to know:

• Do not transfer the .git folder using tools.
• Do not touch the .git folder.
• If there are any environment transfers, check the functionality of git after the transfer.
• Clarify with the client if possible what changes are on production.

7. Branch Naming Rules

7.1. Proper Branch Naming

7.1.1. If Checklists are Large

Branch names should contain the task number and checklist under which the work is being done, and the checklist item.
Thus, when performing a task, the branch will look like this:
ih/taskNumber-Checklist/briefTaskDescription

• ih means inhouse, i.e., a regular employee.
• os means outstaff, i.e., a contractor.
• taskNumber - always indicate the task number.
• Checklist - always indicate the checklist number.
• briefTaskDescription — this is 2 - 4 words.

Example of a correctly named branch:
ih/54361-3/updateCatalogStyles
In branches, it is important to write task numbers and checklists in commits:
git commit -m "task-22333, buglist-1,2"

7.1.2. If Checklists are Small and Do Not Need to be Transferred Separately

Branch names should contain the task number.
Thus, when performing a task, the branch will look like this:
ih/taskNumber/briefTaskDescription

• ih means inhouse, i.e., a regular employee.
• os means outstaff, i.e., a contractor.
• taskNumber - always indicate the task number.
• briefTaskDescription — this is 2 - 4 words.

Example of a correctly named branch:
ih/54361/updateCatalogStyles
In branches, it is important to write task numbers and checklists in commits
git commit -m "task-22333, buglist-1,2"

7.2. Branch Naming with Bugs

7.2.1. Branch Naming with Bugs for a Single Checklist Item

ih/54361-3/bugFix

7.2.2. Branch Naming with Bugs for the Entire Task

#This branch is used for mass bug fixes
ih/54361/bugFix

7.3. Edge Case in Branch Naming

In case the work is not tied to a specific task for some reason, the naming is as follows:
ih/yearday/briefTaskDescription
Example of an alternatively named branch if there is no task for it:
ih/2107/checkoutRefactoring

8. Commit Naming Rules

Commit names should reflect the essence of the work done.
The commit name must include the task number and the number of the task item.
Example:"54361-1 import elements to offers iblock" Where 54361-1 is the task number and the item number separated by a hyphen.

9. If the Edited File is Not Properly Formatted (PSR, Line Breaks)

If you have to work with existing code in a file and that code is not properly formatted, if we make changes and format the entire file, the commit will not clearly show what was changed.
To prevent this problem, you need to:

• Before starting work, format the file according to the code writing guidelines (in PHPStorm, use [CTRL] + [ALT] + L) and commit, ensuring PHPStorm is correctly set up for PSR and the PHP version. In the commit, indicate that this is formatting.
• Start working only after the formatting commit.

10. Working with Layout and Styles

A backend developer does not directly edit styles or layout in the backend branch. A separate repository is used for working with layouts. Follow the rules for working with build tools.

11. Clarifications for Rules on Moving Edits to Production (Specific Case to Item 5)

A new branch must be updated each time before execution, and from it, something that cannot yet be transferred may be pulled from the pre-production branch.
Since a long queue of moving edits to production is expected in this project and extended time for accepting new functionality from different blocks, it is necessary to:

• All commits (hashes) related to the completed task item must be listed.
• Transfers should be made in whole blocks to production (logically completed blocks), not in parts, to prevent conflicts and bugs due to overlapping commits.
• Transfers should be made with release branches like: release/20210408 where 20210408 is today's date.
• Developments should be transferred to the release branch using the command: git cherry-pick commit.

You need to be in the branch where you want to transfer the commit using the command git cherry-pick commit.
If the commit to be transferred is not in your local git, you first need to fetch changes from other branches to your git (the command in your branch from other branches won't merge anything) git fetch origin git fetch - fetches data into your local repository but does not merge it with any of your developments and does not modify what you are currently working on. You need to manually merge this data with yours when you are ready.

12. Commands Useful for Team Lead

12.1 Command to Add New Changes to the Last Commit

The command is useful but not simple. After that, you won't be able to push changes to the repository. You first need to pull and resolve conflicts in the added file.

git add file  
git commit --amend --no-edit

13. Other

In any unclear situations, refer to the GIT documentation of the primary source. If no solution is found, seek help from colleagues (programmers, team lead).

Verification (examination) of operational documentation from the vendor, community for information on support and updates, including vulnerability fixes.

Identification and Authentication

For user identification when accessing, each user must be assigned a unique personal identifier.

User access must be implemented through password authentication.

Feedback protection when entering authentication information must be ensured.

The local password policy must meet the following requirements:

• password complexity policy;

• password history retention;

• password expiration settings;

• the ability to change the password upon first login;

• the ability for users to independently change their password

Integration capability with an identity management system.

User authorization for access should only occur after identification and authentication procedures have been completed.

Support for multi-factor authentication mechanisms.

Access Management.

Access Management

Registration and Accounting of Information Security Events

• registration of the date and time of user login/logout attempts;

• registration of component start/stop times;

• registration of changes in user privileges;

• registration of configuration changes;

• registration of administrator actions;

• registration of user actions

Software Protection

Ensuring Integrity

Network Security

Cryptographic Protection

NDV Control