Details

Published: 15 January 2021

• cypress
• tests

Cypress is a next generation front end testing tool built for the modern web.

Instead of using an external listener, such as Selenium, which can be 'flaky' at times waiting for responses, Cypress has been built to run in the browser so it can more accurately monitor and react to requests. More information can be found at Cypress.io

The following will install Cypress, give some configuration and organization recommendations, and show how to persist sessions. Writing the tests is up to you! (Write your first test)


Install
In the base of your application, make a tests directory, and a cypress directory, as you may have or end up using other test suites
> mkdir tests/cypress
> cd tests/cypress

Simple npm install
> npm install cypress --save-dev

run Cypress
> npx cypress open

Official docs Install Cypress


Organization
While the install of Cypress creates an example skeleton directory
test/cypress/cypress
It is recommended to create your own directory 'just in case' a npm update decides to do 'something' with those skeleton directories.

create an app or unique name under
tests/cypress/[app_abbrev]
You can copy from
tests/cypress/cypress
or create the directories:

• integration

• fixtures

• plugins

• screenshots

• support

• • commands

• • callbacks

Configuration
Under
tests/cypress
create three config files,
cypress.json
cypress.env.json
cypress.env.json.example

cypress.json contains global configuration related to Cypress
Add your [app_abbrev] location to the config:
{
}

cypress.env.json contains environment dependent configuration, such as user names for logins
You should create and maintain a
cypress.env.json.example
with the available config options too
An example config:
{ }

Note, while Cypress does have a baseUrl config option that can be added to cypress.json, doing so does not allow the url to change per environment/developer/tester. If you are using a defined centralized test environment, or defined containers, then this should not be an issue. But to allow the url the app uses during testing to vary between environment/developer/tester, you can add and use your own base url by adding it to cypress.env.json

So instead of
Cypress.config().baseUrl
You would use
Cypress.env("web_base_url")


Support
The index.js in support is called on every run of a test.
This is where you can add global tests configuration and behaviors
Note, for easier maintenance, try to keep functionality to one file.

Update
tests/cypress/[app_abbrev]/support/index.js
to contain
import './commands/login_ui';

import './callbacks/stop_on_failure';
import './callbacks/preserve_session';

Support Commands
An example of a common executed test step may be to log in to your app.

Login UI
support/commands/login_ui.js
Create and add the minimal steps to log into your app, which may look similar to:
// https://on.cypress.io/custom-commands
Cypress.Commands.add("login_ui", (email, password) => { });

Note, instead of using your apps ui to log in for every test, you should create a token or api access to expedite the test

Now you can call the command using one consistent statement

describe("Select that Awesome Thing Test", () => { });

Support Callbacks/Behaviors

Stop on Failure:
support/callbacks/stop_on_failure.js
When on step of a test fails, it will often cause the next steps to fail.
So fail early so the problem can be found quicker.
Create and add
// after each test
// stop test after first failure
afterEach(function () { });

Preserve Sessions:
support/callbacks/preserve_session.js
All tests are supposed to be isolated, so Cypress will often clean up your cookies.
While it would be nice if the cleanup happens after the first test, or the last test in a suite, the clean up will happen after a few tests, which can log you out of your app and make it seem like your app or the test are broken.
To persists your session, which is often stored in a session cookie, create and add:
// once before all tests
// preserve session cookie so don't get 'randomly' logged out after several specs
before(function () { });


Package.json
While you can run Cypress via
> npx cypress open

You can also add a more common alias to your package.json
"scripts": { },

And run Cypress via
> npm run test


.gitignore
Update your .gitignore
/tests/cypress/node_modules
/tests/cypress/cypress
/tests/cypress/cypress.env.json


Hopefully the above information helps you setup and use Cypress in a more enjoyable and useful fashion.

Details

Published: 16 December 2020

• aws
• s3

By putting a cleanup Lifecycle rule in place on your S3 buckets, you may be able to potentially save costs and increase LIST performance.

"Incomplete Multipart Uploads – S3’s multipart upload feature accelerates the uploading of large objects by allowing you to split them up into logical parts that can be uploaded in parallel.  If you initiate a multipart upload but never finish it, the in-progress upload occupies some storage space and will incur storage charges. However, these uploads are not visible when you list the contents of a bucket and (until today’s release) had to be explicitly removed.

Expired Object Delete Markers – S3’s versioning feature allows you to preserve, retrieve, and restore every version of every object stored in a versioned bucket. When you delete a versioned object, a delete marker is created. If all previous versions of the object subsequently expire, an expired object delete marker is left. These markers do not incur storage charges. However, removing unneeded delete markers can improve the performance of S3’s LIST operation."

Source: https://aws.amazon.com/blogs/aws/s3-lifecycle-management-update-support-for-multipart-uploads-and-delete-markers/

To add a cleanup Lifecycle rule:

• Log into the Amazon S3 web console
• Select your S3 bucket

• Select Management
• Select Add lifecycle rule

• Enter a name such as 

'Delete incomplete multipart upload and Delete previous versions'

• Skip Transitions for now

Transitions allow you to move storage to slower locations at a reduced cost
https://docs.aws.amazon.com/AmazonS3/latest/dev/lifecycle-transition-general-considerations.html

• Expiration
  • Delete Previous versions after 365 days

You can choose shorter periods such as 7 days or 30 days if you don’’t have a use case for retrieving prior S3 versions.
You will still have the current version, which is usually all you want, but deleting previous versions can help with costs and S3 LIST performance.

• • Clean up incomplete multipart uploads after 7 days

If you do not have any automated processes that may re-try uploads, you could choose 1 day

• Review

Agree to the 'scary' this applies to all objects in bucket
Note, if you have S3 objects (uploads) which require different policies, you may find it easier to manage by creating a S3 bucket per policy.

You now have some basic cleanup of your S3 bucket(s) configured.

Details

Published: 16 November 2020

• composer
• php

Details

Published: 26 October 2020

• git

Most Git workflows do not address picking what is released. Once a feature branch has been merged back to 'development', it is in the release pipe, pending QA and Business validation.  Once in 'development', code/branches cannot easily or arbitrarily be plucked out to go directly to production as the code is often intermingled with other branches.  But the code changes in 'development' can be manually re-coded (Git patches help) into a hotfix branch from 'master'/'production' with the risk of not being QA-ed.

The 'Git single branch strategy' primarily removes the pain point of the conflicts between 'master' and 'development', while providing a clearer history of production releases, and an easier rollback with switching branches.

Generally picking what to release is largely mitigated by how, and the order in which Tickets are chosen. However, the release pipe can be slowed down by a Ticket/branch needing time to fix, or be validated by QA or Business.  To remove the blocking branch, depending on the changes, the feature could be hidden, or removed if a small change, or more likely wait for the fix(es) and QA.

Hopefully the upfront choosing of Tickets and quality of specifications somewhat mitigates the blockers.

Some Git strategies to mitigate blockers in the release pipe, which are caused by Tickets that often require feedback once seen.

1) Put less in the release pipe: (Less is more)

If limit releases to one branch per release, then there is no re-picking once in 'development'.  Basically the other feature branches would queue up waiting to be picked and for merge to 'development' and QA-ed.  Which leads to the pros and cons of Staging branches.

2) Staging branches:

Another process to maybe help with picking branches for release is to not merge feature branches back to 'development' until picked.  The feature branches could be deployed to their own directory (devsite.com/branch/123-shortdesc) be QA-ed, reviewed by Business, then if ok, merged to 'development'.  Then when decided to go to production, everything currently in 'development' is QA-ed again, fixes added via branch updates or a new branch, and then released via 'master'/'production'.  

Note, if after being merged to 'development', production release decisions change, well, then we are back to the same problem of doing hotfixes, or hiding not ready functionality, or waiting for the fixes.

Also this approach can be a burden on the developers: fixes enhancements, code cleanups, won't be seen or utilized until the branch is picked, and those fixes/enhancements might be required or desired for another branch, thus duplication of code which probably means conflicts later.  Before merging the feature branch to 'development', 'development' would need to be merged back to the feature branch to handle any changes or conflicts in the branch, so the developer can test again before merging to 'development'.  And as the code won't be fresh on the developers mind, there is a higher risk of mistakes to be made during the merge to 'development'.

pros: 

• able to preview branches before release
• able to choose branches for release

cons:

• more work for Business and/or QA as the merged branches in ‘development’ still need to  be reviewed
• if decisions change to remove a branch or hotfix a branch to production before qa, same problems
• more burden on developers, potential conflicts, developing the branch twice: once orig, then later (days, weeks) when picked
• dev-ops + some app work to make 'their own directory' happen

Committing often, merging often seems to be better for code quality.

3) Feedback branches, Preview branches: (A hybrid of Staging branches)

For branches which require Business or early QA feedback, after development is done, but before QA or merging to 'development', push the branch to a preview location (devsite.com/branch/123-shortdesc).  There it can be previewed for one or two days, before being merged to 'development' and moved to QA; required feedback branches should not be held for a long time, else the cons of Staged branches may become apparent.  The branches that require feedback should be marked as such before development.  Every branch should not be marked as requires feedback, only a few should be.

pros: 

• able to preview branches marked as feedback before release
• should reduce fixes needed when in 'development' for QA
• as only a day or two delay, no large time incurred burden on developers

cons:

• does not allow changing order of released branches
• more work for Business and/or QA as the merged branches in ‘development’ still need to  be reviewed
• if decisions change to remove a branch or hotfix a branch to production before QA, same problems
• dev-ops work  + some app work to make 'preview location' happen

Hopefully some useful Git strategies when dealing with Tickets that often require feedback once seen.

-End of Document-
Thanks for reading