co-sharelib v1.0.0

Shared Library Project

Goal:

Starter Project goals – Starter project should make development, deployment, testing, and measuring/tracking fast, repeatable (better quality as result), and enable consistent user experience across sites.

Breaking down the stated goal:

Development – Starting development of a new project we as developers shouldn’t have to think how to setup our AWS infrastructure, CMS (Prismic Custom types), and should reuse common React components in order to move fast and sustain quality. We should be able to execute a single command that pulls down the Starter project and puts the contents into a new directory e.g. Starting smb site we should be able to do the following smb and this creates a new folder, smb, with all of the starter project contents. Next, we should setup git. Next, we deploy our Pipeline (Infrastructure as code so this is just another command). Next, we run Prismic theme (or whatever the CMS of the day) and populate the Home page content. Finally, we run our first build. This builds out our dev AWS infrastructure, test our code (Home page be the only thing to test), and deploys to QA. The pipeline (see deployment) ask (not required) if we would like to deploy to Staging. Next, asks (not required) to deploy to Production if you deployed to Staging in last step. Please see Starter Project structure and Starter Project usage for more details.

Deployment – CI/CD Pipeline setup should be codified, meaning it can be versioned controlled and enables you to repeatably replicate the pipeline as new projects come up. CI/CD Pipeline should enable Continuous Delivery, i.e. enables us (but doesn’t necessitate) to deliver new features as soon as they pass Testing phase and Not force us to wait until the sprint is finished to deploy the release all at once. I.e. The delivery pipeline has stopping points at each environment to have a human approve / disapprove the next step. E.g. After the test phase passes in QA, the pipeline will wait to see if you would like to promote these changes to Staging. Finally, it will do the same for Production. This rapid delivery model becomes fruitful especially if/when we start measuring/tracking as the more time capturing data points gives you the most feedback possible to make data driven decisions.

Testing – Testing should be fast and ensure quality by doing testing in layers. Layers of Testing should be unit testing, functional testing, Look and feel testing, and Performance / SEO testing. Testing should be fast and easy for developers to do; we shouldn’t have to wait on each other to test our branches and the result of the test should take minimal amount of time as possible. We should test early and often, i.e. we should test as we are writing the code (unit / functional), then after we are satisfy we can test our feature in our own sandbox independent of the integration branch (develop), finally, after our feature works standalone, we can pull request / merge it into develop which this git commit initiates the continuous delivery pipeline to start.

Measuring / Tracking - Measuring / Tracking is the most important thing we can do in our marketing websites and we should treat it accordingly. The data we collect should have the end in mind, i.e. we should think of the personas and what/why each of them want certain data. Measuring / Tracking should just work for generic measures Page Views, button clicks, session time, device info, region, video metrics. Also, it should have the capability to track custom metrics.