¶ What sites should be setup and when?
- The developer would spin up CEF/DNN/OtherApplication locally first.
- The developer would then stage and commit their code to a development branch in ADO.
- The development branch would be used to deploy to the DEV/QA instance on the devforceone. This branch would be cloned and would become the QA instance per our current source control/branch policies.
- Development would take place and after a series of commits, followed by a push to the feature branch, that completes the User Story being worked on, a pull request would be made from the developers feature branch (bug branch respectively) into dev.
- The pull request process is followed and the code is either pushed back to the developer or if approved would be allowed to merge with the dev branch, where it would then need to be deployed to the dev/QA environment for testing.
- If a PR is approved and deployed, the User Story that is worked on would then go into a state of deployed to QA triggering our QA Engineer to begin his QA process on that User Story.
- If the QA process passes, the ticket state is changed from deployed to QA to passed QA. If the QA process fails, the ticket state is changed from deployed to QA to failed QA. Failed QA would kick the User Story back to the developer with feedback on why it failed, and this cycle continues until is passes QA.
- All tickets that pass QA would then have a pull request created to merge the dev branch's working User Stories / Features into the Stage/UAT branch.
- If the PR is approved following our PR approval process (that differs for front end and back end alike) then the merge would be completed, and the updated branch would be deployed to the staging environment. If a staging branch does not exist at this time, one is created, and the environment is spun up by cloning that branch.
- The staging environment should have working and functionally tested code. At this point we would begin UAT and non-functional testing. Examples of non-functional testing would be load-testing and performance test of the application that is under development.
- If the UAT/Stage process passes non-functional tests and gets the approval from the client it can then be merged (via PR process) into a production branch which will be used at that time or later to create the production environment via cloning the code from that branch.
Items going from QA to Stage require approval from the PM, the QA engineer, and the lead developer or code reviewer (PR approver).
¶ Where is the standard documentation for developers (already exists)?
- The standard documentation for process can be found by searching in SharePoint or Nuclino.
- This documentation is maintained by the dev team, and can all be found in the Clarity Teams Development channel files.
- With our current process we have designated front end and back end deployers who would approve PR's and managed and deploy code from source control in ADO.
¶ Differences Between CEF, DNN, Combo, and other types of development in regards to setup?
- DNN is fairly easy to setup and requires a database and the DNN installation (if out of box).
- If we are working on an existing DNN site, we need the webroot folder and the database in order to wire that up on our end.
- For CEF/DNN and Combo the setup is much more in depth as CEF has a lot of dependencies and artifacts that require specific versioning in order to function. There are also multiple databases involved, especially if Clarity Connect is involved.