About GitHub:
GitHub is a platform where you can upload a copy of your Git repository (often shortened to repo), hosted either on GitHub.com, by your company on a cloud provider (like Azure, AWS, or IBM Bluemix), or on your company’s own servers behind its firewall.
Git is a version control system. A version control system is a piece of software designed to keep track of the changes made to files over time. More specifically, Git is a distributed version control system, which means that everyone working with a project in Git has a copy of the full history of the project, not just the current state of the files.
Changes managed by GitHub:
Access to branch, deploy, approve, and merge changes to critical GitHub repos is restricted. A merge is a way to take completed work from one branch and incorporate it into another branch. Most commonly you’ll merge a feature branch into the master branch. Example usage: “Great job on the ‘my account’ feature. Could you merge it into master so we can push it to production?”
Depending on the change, developers will test locally and use automated CI/CD testing. Once pre-production testing has validated the change is functioning as expected and all required reviews and approvals are complete, the branch is merged into the Main Branch and is rolled out in staged releases via Canary deployments to GitHub’s Kubernetes clusters in production for customer use. Is there any tool run to detect insecure coding practices? Requirements for performing an effective peer review are documented on The Hub and in repo-specific Pull Request templates.
Once the code is ready for discussion and review, developers open a Pull Request for commits added to their branch following the template. Whenever you save your changes in one or more files, you can create a new commit in Git. A commit is like a snapshot of your entire repository at that point in time, not just of one or two files. So naturally, after you change those files, you will want to update the repository by taking a new snapshot.
Pull Requests: PRs are an integral feature of GitHub used to coordinate the discussion, approval, testing, and deployment of changes. Protected branches (branches where merging to the Main branch is gated by required review and approval activities) are also enabled on Enterprise Cloud code repositories. Protected branches require that PRs are reviewed and approved by an individual who is different than proposer of the change prior to merging the code to the Main Branch. A branch is an independent series of commits off to one side that you can use to try out an experiment or create a new feature.
GitHub Change Process:
- CREATE A BRANCH: Create a branch in your project where safely experiment and make changes.
- ADD COMMITS: Whenever you add, edi or delete a fie, you’re making a commi, and adding them to your branch when you are ready you may push your commits to the remote repo
- OPEN A PULL REQUEST: Use a pul request to get feedback on your changes from people down the hall or ten time zones.
- DISCUSS AND REVIEW: Once a Pull Request has been opened, the person or team reviewing your changes may nave questions or comments.
- DEPLOY: Once your pull request has been reviewed and the branch passes your tests, you can deploy your changes to verify them in production. If your branch causes issues, you can roll it back by deploying the existing master into production.
- MERGE: Now that your changes have been verified in production, it is time to marge your code
Into the master branch.
Changes in the cloud
To rapidly build and provision a virtual machine and then deploy applications through a fully automated deployment pipeline have quickly become expected capabilities.
The applications running on multiple servers (via a load balancer or proxy) and updated during the working day without any impact to end users is even more exciting.
Types of tests:
- Unit testing verifies that stand-alone programs match specifications. Test cases should exercise every line of code.
- Integration testing verifies that all software and hardware components work together. Data is passed from one program to the next. All programs and subroutines should be tested during this phase. Test cases should cover all components (e.g., hardware and software). Validates that individual components and services correctly work together across environments like SIT and Testing.
- Functional testing verifies that the application meets user requirements.
Test cases should cover screens, navigation, function keys, online help, processing, and output (reports, files, and screens). Ensures features perform according to requirements, primarily in Testing and UAT. - Technical testing verifies that the application works in the production environment. Test cases should include error processing and recovery, performance, storage requirements, hardware compatibility, and security (e.g., screens, data, and programs).
- User Acceptance testing verifies that acceptance criteria defined during the project definition stage are tested. Test cases should include system usability, management reports, performance measurements, documentation and procedures, training (e.g., users, help desk, production support, and operations), and system readiness (operations/ systems sign-off). It ensures that the application fulfills the agreed-upon functional expectations of the users, meets established usability criteria, and satisfies performance guidelines before being implemented into production. Acceptance testing minimizes the risks that the new application will cause business interruptions or be disjointed with business processes.
- Post-implementation reviews help us understand what went well and what could be improved in the change management process. Post-implementation reviews help us understand what went well and what could be improved in the change management process. A well-controlled implementation phase minimizes production issues such as system bugs, performance issues, misunderstood expectations, and misaligned staffing.
- UI Testing: Focuses on verifying the user interface in Testing and UAT environments.
Change Management
The updates are delivered through three pipelines:
A. Production environment changes
B. Customer-facing updates
C. Open-source code releases
Process:
• Change Process Initiation: Developers check out source code, modify it, and undergo testing and code reviews.
• Code Review Requirements: It mandates independent production code reviews by developers following coding standards.
• Emergency Change Management: Emergency changes to production environments require justification, logging, monitoring, and review.
The release consists of multiple environments, each serving a specific purpose in the software delivery pipeline. They include:
1. Development Environment
Used by developers to write, compile, and build the code.
Allows initial unit testing and verification of new features.
Focuses on code functionality rather than extensive testing.
2. Testing Environment
Dedicated to performing various testing activities.
Includes UI testing (verifying user interface components), functional testing (ensuring the system behaves as expected), and integration testing (checking how different modules interact together).
3. SIT (System Integration Testing) Environment
Used to validate that all parts of the application and integrated systems work together.
Emphasizes integration testing extensively.
Often includes mock services or connected downstream systems for realistic testing.
4. UAT (User Acceptance Testing) Environment
Mimics production conditions closely.
Used by business users or clients to perform functional testing and ensure the system meets their requirements.
Typically the last stage where feedback is given before deployment to production.
5. Preproduction Environment
A staging environment that is almost identical to production.
Used for final validation, load testing, and sanity checks before go-live.
6. Production Environment
Live system where end-users access the application.
No direct testing is performed here except for monitoring and hotfix validations.
Data Centric 