\
(roughly a 50% decrease!)
- What are our goals with it?
- To decrease unnecessarily large CSS files. This applies to all-encompassing CSS files (main.css, all.css, etc.) but also to landing pages, where UnusedCSS can give you the CSS that’s only needed for that page and leaving out the rest. This increases page optimization even more, as well as SEO performance.
- The process to Follow – Begin Development
- Preparing for Development (New Feature / Feature Fix)
- Pulling a local instance for development
- The Clarity-Ventures.com (CV) production site repository can be found at https://clarity-ventures.visualstudio.com/DefaultCollection/CVI-Production-Website-CVI.com/_git/CVI-PROD-DNN9
- The production databases are hosted on the same server the production instance is hosted on. (This can be accessed with the SSMS on the server, credential not included for security)
- ClarityCustomEntity: _CLARITY_V10
- SiteSqlProvider (DNN): DNN9_CVI
- New feature / fix for CV should be pulled from the development branch ‘support/clients/clarity/qa’ (dev branch should always be up to date with production due to the merge-local first methodology)
- Branch naming convention should follow the Clarity Client branch naming convention
- support/clients/clarity/feature/<short name of feature> - for feature development
- support/clients/clarity/bug/<short name of bug fix> - for bug fixes
- support/clients/clarity/hot-fix/<short name of hot-fixes> - for hot-fixes
*Please note support/clients/clarity/qa, support/clients/clarity/uat, and support/clients/clarity/production should NOT be used for cloned branch name, as these are branches that are the target stage for pull requests and will need to stay sanitized for Quality Assurance and Testing purposes.
- Once a “clone” branch is created following the naming convention, a local version should be copied to the developer machine along with a backup database of the two connection variables above. (Making sure to change the connectionString variables in the web.config to point to a local restored SQL Express instance) *Important to note that “pull requests” are a workflow method and are not a feature of the version control system itself.
- When the feature/fix for CV is completed locally, the developer should merge the newest version of ‘support/clients/clarity/qa’ into the local development branch and resolve all conflicts and error before a pull request can be submitted to pull the locally merged/resolved development branch into QA.
- Any changes to either database (‘Clarity_V10’ and ‘DNN9_CVI ‘) will need to be manually deployed to the QA database.
Please Note: All manual database changes will need to be documented and commented in the PR request / attached to the pull request for review and tracking purposes.
- Preparing for Deployment
- What is a Pull Request (PR Request)
- A pull request is a method of submitting contributions to a development project. It is often the preferred way of submitting contributions to a project using a distributed version control system (DVCS) such as Git. A pull request occurs when a developer asks for changes committed to an external repository to be considered for inclusion in a project’s main repository.
- It is important to note that “pull requests” are a workflow method, and are not a feature of the version control system itself.
- How Does a Developer Make a PR with Azure
- Login to the Clarity Ventures dev.azure.com website.
- From the side navigation bar go to Repos > Branches to check that the local development branch (following the standard Clarity Branch naming convention) has been pushed up to the remote Azure repo. If the push was recent (less than one hour) you should see a quick link
- Once branch push is validated, from the side navigation, go to Repos > Pull requests
- Make sure you are viewing ‘Mine’ pull requests
- Click on ‘New pull request’ on the top right-hand side of the azure window.
- Fill out the required information, this includes the source branch into the target branch, the work item ticket, and the proper approver(s).
- There should not be a merge conflict when submitting a pull request, the development branch should have been merged locally first to resolve all merge issues prior to submitting a PR.
4. When all stakeholder/code reviewer/approvers have approved and completed the pull request, the pull-from source branch is then removed from the remote repository (but not from any local repository)
- How Does a Developer Make a PR with Command Line
git request-pull [-p] <start> <url> [<end>]
-p: Include patch text in the output.
<start>: Commit to start at. This names a commit that is already in the upstream history.
<url>: The repository URL to be pulled from.
<end>: Commit to end at (defaults to HEAD).
*This names the commit at the tip of the history you are asking to be pulled.
When the repository named by <url> has the commit at a tip of a ref that is different from
the ref you have locally, you can use the <local>:<remote> syntax, to have its local
name, a colon :, and its remote name.
\
- Imagine that you built your work on your personal_branch on top of the master release, and want it to be integrated into the project. First push your master branched personal_branch to the repository:
git push . personal_branch
- Then, you run this command:
git request-pull master personal_branch
which will produce a request to the upstream, summarizing the changes between the personal_branch release and your master, to pull it from your public repository.
- If you pushed your change to a branch whose name is different from the one you have locally, e.g.
git push master:for-linus
- Then you can ask that to be pulled with
git request-pull personal_branch master:for-linus
- What Happens When I Make a PR Request
- The PR must get a series of reviewers for approval.
- Primary Reviewer - completes an initial review of the PR and is allowed to add comments as either requirements or suggestions regarding the changes or requirements and will block the PR until they are addressed.
- Backup Reviewer - completes the initial review when the Primary Reviewer is the author of the code needing review.
- Executive Reviewer - completes a secondary review of the PR. The Executive Reviewer is allowed to resolve comments from the Primary Reviewer at his or her discretion. They may also add further comments to the PR. The Executive Reviewer may block portions of code in the PR or reject the PR in its entirety pursuant to the PR rejection criteria.
- What Will the Reviewer Look for in the PR Review
- Code file(s) update / created within the PR to be merged into the targeted branch.
- Coding best practices and standards relevant to the teams it affects, Front-End (FE), Back-End (BE).
* This includes but is not limited to proper error handling, Run-Time efficiency and code readability.
- Valid Reasons for PR Rejection.
- The code is highly specialized to a client-specific workflow and is non-reusable in a general setting.
- The code does not follow best coding practices and standards for the appropriate FE / BE.
- Business logic, features or etc, that the Stakeholders has not validated.
- PR in which unrelated file changes have been committed (intentional or unintentional).
- Reviewer(s) comments / request-for-change had not been resolved.
- PR older than 3 days and code issues are not resolved / or have gone stale are automatically rejected.
- Database Schema or T4 file changes that do not have prior Stakeholder(s) approval will be rejected.
- Tagging Items for Later Work
- There may be features / tasks that a reviewer can notate or tag for future iterations of code development. This feature(s) / task(s) is not related to the current task but will improve upon the functionality of the current work.
IE: Code that increases Run-Time efficiency or end-user experiences within the platform.
- What is the Best Way to Communicate
- Direct message to the reviewer to address issues concerning the PR. This can be in-person, email or DM via Microsoft Teams
- PR Comments can be used to flag granular issues within the PR that highlight importance and specific change requests prior to reviewer approval.
- Testing PR Branches
- Large PR changes (Potential Breaking Changes)
- Including migrations and T4 alterations require regression testing. These PRs
would have a branch testing site spun up for QA to utilize to test
the PR prior to the branch merger.
- Regression Testing
- Smoke-Test and Feature Testing- Standard Smoke Test of Happy Path
Features, combined with Feature Testing based on the altered
section(s) identified by the author of the PR
- Full Regression- Full main feature testing of site. Need to edge
test or permutation testing will be identified based on the
level of risk of breaking changes.
- All Changes Published to Dev QA Branch
- Use git to local merge and resolve issues prior to pr request and code submission.
- Any required database changes (including but not limited to content, modules setting changes, inline styling, etc..) are required to be documented and submitted along with the pull request. Failure to do so can result in database content clash and race condition between target source or site regression.
- Make sure the development QA branch is manually pulled from the remote into the hosting DFO server. Any code merges conflict on the DFO QA / Dev branch will need to be documented and confirmed by the developer either for disposal or merge into the pull as active but not approved code.
- Pre-Deployment QA
- Run ScreamingFrog against Production Website
- Hold onto this for post-deployment comparison
- Smoke Test or Regression Test?
- Smoke-Test and Feature Testing - Standard Smoke Test of Happy Path
Features, combined with Feature Testing based on the altered
section(s) identified by the author of the PR
- Full Regression - Full main feature testing of site. Need to edge
test or permutation testing will be identified based on the
level of risk of breaking changes.
- Smoke Testing Checklist
- Cross-Browser & Cross-Operating System
- Firefox
- Responsive Testing
- Skin Specific Testing
- IE11 Test
- Chrome X test
- Opera X
- Safari X
- Windows
- Mac
- Linux
- Responsive Testing
- Widescreen test
- Page Layout
- Text Legibility
- Image Responsive Sizing
- Navigational Menus
- RFQ Testing
- 1024 x 768 Test
- iPhone Test
- Android Test
- iPad Test
- Skin Specific Testing
- When creating new skins or removing old, run the following code snippet in the database to pull a list of the unique skins being used:
SELECT
DISTINCT
SkinSrc,
TabPath,
TabName
FROM Tabs
WHERE
SkinSrc IS NOT NULL AND
TabPath NOT LIKE '%Admin%'
ORDER BY
SkinSrc, TabPath, TabName
- home (https://www.clarity-ventures.com/)
- Main navigation
- Test Links
- Footer Navigation
- Test links
- Test Site Search
- Layout / Responsive
- In BrowserStack, check the OS and browser layouts / responsive nature
- Unique functionality
- Any unique functionality on the page needs to be tested (i.e. tabs, accordions, sliders, modules, etc.)
- RFQ
- cef-home (https://www.clarity-ventures.com/ecommerce)
- Integration panels hover effect
- cef-child (https://www.clarity-ventures.com/ecommerce/international-multilingual)
- connect-home (https://www.clarity-ventures.com/ecommerce-integrations)
- Integration panels hover effect
- connect-child (https://www.clarity-ventures.com/ecommerce-integrations/api-ecommerce-integration)
- resource-center (https://www.clarity-ventures.com/ecommerce-integrations/woocommerce-integrations)
- Tab navigation
- “Features & Pricing” accordion tabs
- services-details (https://www.clarity-ventures.com/services/web-design)
- article-list (https://www.clarity-ventures.com/resource-center)
- Search for an article
- Filter functionality
- Test pagination
- Click into an article detail page
- On the article detail page, test the “download for later”
- In the banner navigate back to home
- directory (https://www.clarity-ventures.com/integrations)
- Navigate through the additional pages
- Click on one integration (lands on first detail page)
- Click on an additional integration (lands on the final detail page)
- about-us (https://www.clarity-ventures.com/about)
- careers (https://www.clarity-ventures.com/careers)
- partners (https://www.clarity-ventures.com/partners)
- contact-us (https://www.clarity-ventures.com/contact )
- our-team (https://www.clarity-ventures.com/about/our-team)
- Click on a team member
- On the team member detail page, navigate to an additional team member
- portfolio (https://www.clarity-ventures.com/portfolio)
- Navigate to a portfolio detail page
- Bottom of page navigation to another project case study (pagination arrows)
- demo-site-landing (https://www.clarity-ventures.com/demo-site)
- Navigate to a detail page
- On the detail page, use the navigation arrows on the top to go to another “demo site”
- Click the center button in the top nav to go back to the demo site home page
- RFQ Testing
- Click request for quote button
- Submit an RFQ
- Validate by referring to the RFQ email
- Regression Testing Checklist
- 1. Resource Center
- 2. Glossary Pages
- 3. Sitemaps
- 4. RFQ Buttons and Form Modal
- 5. …
- Pre-Deployment QA Backup [All Testing]
- Databases
- Backup the _Clarity_V10_QA database
- Include a reference to the date, for example:
- _Clarity_V10_QA_2020_09_10.bak
- Backup the DNN_CLARITY database
- Include a reference to the date, for example:
- DNN9_CLARITY_QA_2020_09_10.bak
- Application Files
- Create a backup of the application folder
- Use 7zip to create 250M chunks and store within the _archive or _backup folder within the application’s parent directory
- Move the chunked backup files into a directory with today’s date, for example:
- 2020_09_10
- Live_01.7z
- Live_02.7z
- Live_03.7z
- Pre-Deployment QA [Full Regression Testing]
- Set up a copy of the application files as the next version of the QA site, for example
- If the folder root is “Live”, then it might be Live_QA_2020_09_10
- Point QA site at the new folder
- Set up a copy of the database files with a suffix of the date on SQL, for example:
- _Clarity_V10_QA_2020_09_10
- DNN_Clarity_QA_2020_09_10
- Modify the application files to point at the databases above
- Validate that QA site loads and resolves properly
- Set up robots.txt to ignore/not index the entire site
- IMPORTANT! Do not commit this to source control and make sure to resolve this on production deployment.
- Setup IP blocking where applicable to ensure no external site access
- Run and validate unused CSS if applicable
- Run testing against deployed QA
- Complete partial or full regression testing
- Make sure all testing criteria pass, if any testing step failed, identify the reason and seek stakeholder approval for an override on testing result.
- The test includes but it not limited to Selenium Testing Criteria (Please refer to the Selenium Testing and Setup Steps)
- Ensure any changes are committed and pushed to respective repo(s)
- QA Deployment [All Testing]
- Bring over any database schema or database record changes
- Ensure recent backup (within minutes) completed in the event a restore is needed
- Pull latest files into live/extensions folders from pushes to QA
- Build and ensure deployment completes as expected
- Complete smoke test to ensure site loading properly
- Swap out of maintenance/older version of site and direct at new version
- Post-Deployment QA
- Run ScreamingFrog against Production Website
- Compare with Pre-Deployment ScreamingFrog Results to ensure all manual changes are secure and made it into the QA / Dev development database.
- RUN THROUGH THE PRE-DEPLOYMENT QA STEPS, including all stages of testing/regression/risk identification.
- UAT Pre / During / Post Deployment [All Testing]
- Follow the same steps from b to h, deviation from the guide is not acceptable.
- PRODUCTION Pre / During / Post Deployment [All Testing]
- Follow the same steps from b to h, deviation from the guide is not acceptable.