Things to move:
Infrastructure Provisioning Use Cases - Enterprise Architecture - Confluence (.com)
DevSecOps Security - DevSecOps Security - Confluence (.com)
DevSecOps On Demand - Home (sharepoint.com)
Work and Test Management Home - Work and Test Management - Confluence (.com)
GitHub Migrations - GitHub at - Confluence
Digital Workplace Portal (sharepoint.com)
Text on those things:
Infrastructure Provisioning Use Cases - Enterprise Architecture - Confluence (.com)
is a large organization and has a diverse and heterogeneous infrastructure environment. This article outlines the known environments, management use-cases, differences, and opportunities for standardization.
Environments
At there are several different on-premise and cloud environments being utilized for infrastructure provisioning.
• Operated Data Centers
o Sterling, VA, USA
o Somerset, NJ, USA
o Durham, NC, USA
o Singapore
o Brussels, Belgium
o Beijing, China
• Cloud Providers
o Amazon Web Services (AWS)
o Google Cloud Platform (GCP)
o Azure DevOps
o Cloudflare
o VMWare Managed Cloud (VMC)
Cloud Management
Focusing on cloud providers, there are several different management services and layers in use. Some of these are organization/division specific and some are shared services across the entire organization. Each has a different target audience, skillset level, and operational model.
Infrastructure on Demand (IoD)
IoD is operated by the Identity and Access Management team. IoD (iodmod..com) utilizes the VMWare Managed Cloud (VMC) platform on AWS to allow users to provision infrastructure based on defined blueprints.
Private Cloud
VMC
The original IoD offering is a private cloud offering utilizing VMC on AWS with hosting options in Virginia, USA; London, UK; and Singapore. This platform is currently considered legacy and is being phased out in favor of Cloud Brokerage.
Cloud Brokerage
AWS
Cloud Brokerage is a public cloud offering which still uses the iodmod..com management interface, but provisions infrastructure into dedicated AWS accounts (non-prod or production). Cloud Brokerage offers a limited set of AWS services compared to the other service offerings.
Cloud Brokerage is supported in the US, EU, Singapore, and China regions.
Rapid
AWS GCP AZURE
The Rapid service offering is available on Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure. Rapid environments allow for native access to a greater number of services than the Cloud Brokerage offering. These environments provide the necessary security controls for teams to develop cloud native solutions, but don't include a high level of digital support. That responsibility falls to the account/environment owner.
The EP&S Digital Hosting Solutions (DHS) team solves for and manages infrastructure controls including identity, network, security, and logging, enabling sensitive data usage and production/GxP use cases. Although initial infrastructure service qualification is completed by the DHS team, application teams will be responsible for meeting certain CRS controls for each service. This environment design provides flexibility for those groups requiring direct console and API access to deploy, configure, and manage cloud-native applications. Application teams that want to truly leverage cloud native capabilities while directly supporting them are well suited for this environment.
Rapid for AWS is supported in US, EU, and Singapore regions. Additional regional support in AWS China is planned.
Azure
The recommendation from Digital Architecture for the Azure platform is to only leverage when ’s primary AWS cloud services cannot meet the required business requirements and desired outcome and Azure offers differentiated business value.
Google Cloud Platform (GCP)
The recommendation from Digital Architecture for the Google Cloud Platform is to only leverage when ’s primary AWS cloud services cannot meet the required business requirements and desired outcome and GCP offers differentiated business value.
Commercial (C&CCC)
AWS
The Customer and Commercial Creation Center (C&CCC) has been operating it's own AWS accounts since 2013. These accounts are externally facing and have no connectivity back to the Network. These accounts have access to the full AWS service catalog. Solutions that need to be externally accessible to clients and customers can be hosted on one of C&CCC's many strategic platforms or ad hoc hosted by the Platform Foundations team.
CLDFLARE
C&CCC also manages and operates the Cloudflare enterprise platform. Cloudflare acts as a security proxy, web application firewall (WAF), content delivery network (CDN), edge compute, and denial of service protection service for our externally facing web properties.
Commercial supports most all AWS regions including China and has the flexibility to use new ones as needed.
Differences
IoD/Cloud Brokerage Rapid Commercial
Developer Experience and Skillset Low-Moderate Moderate-Expert Expert
Cloud Providers AWS AWS
GCP
AZURE AWS
CLDFLARE
Services Available Limited Most All
Console Access No Yes Yes
Network Connectivity Internal Only, Net access Internal Only, Net access External Facing, No Net access
Infrastructure Provisioning ClickOps, Defined Blueprints Manual (Console),
CloudFormation,
Terraform Manual (Console),
CloudFormation,
Terraform
Support and Operations Model Full Support and Ops Limited, Solution Owner Responsibility Limited, Solution Owner Responsibility
DevSecOps Security - DevSecOps Security - Confluence (.com)
What is DevSecOps Security focused on?
The Security Domain aims to embed a proactive approach to integrate cybersecurity measures and prevent security threats early in the application development lifecycle. As a result, this domain manages security tools that test code on the fly, performing security audits without slowing down or otherwise impacting development.
Additionally, the Security Domain aims to underscore the importance of introducing security at all levels of development and aims to automate many of the security processes such that developers are able to deploy code with security included.
Team Information
About Us
Our team looks to ensure that a Software Composition Analysis (SCA) & Static Application Security Testing (SAST) as part of a DevOps Engineers pipeline or incorporated into the development process.
The goal is to ensure SAST testing is done in the development pipeline, and DAST testing is done to test running code. SCA should be done to check open source dependencies (enterprise license will follow). These tools will provide the development community early insights to defects to reduce production surprises.
Workstream Desired Outcomes
• Deliver a cost effective and fully automated SCA / SAST tool that identifies and mitigate risks for DevOps Engineers and Developers.
• Deliver a cost-effective SCA / SAST tool that provides automatic, actionable reports on vulnerable out-of-date libraries in use by Developers and libraries with potential licensing risks.
• License management & utilization – Provide an organization with the benefit of license management & utilization.
Team Members <Collate into a separate page>
• Product Owner: Melissa Riley
• Scrum Master: Heather McNamme
• Scrum Team: Michael Woiten, Philippe Armando
What do SCA and SAST mean?
SCA monitors the security of your library code: code that you use, but do not write.
Software Composition Analysis (SCA) – Encompasses the monitoring and managing of license compliance and security vulnerabilities in the open source/library components of your project. If your jQuery library is out-of-date and vulnerable, SCA will catch it.
Go to SCA - GitHub Dependabot
SAST monitors the security of the code that you write by looking for oversights.
Static Application Security Testing (SAST) - Helps in identifying vulnerabilities in proprietary developed code to detect and remediate potential vulnerabilities early in the DevOps cycle. If your custom-coded "Welcome Banner" is vulnerable, SAST will catch it.
What security tools are included in the DevSecOps pipeline?
GitHub is the source control management (SCM) that will be used across all teams that have adopted the Golden Backbone.
GitHub Dependabot is an SCA tool that is included for free with all GitHub repositories and provides a natural and seamless developer experience within the platform, making it 's preferred SCA tool.
Key features of GitHub Dependabot include:
• Automated workflow for updating vulnerable libraries
• Free-of-charge
• No integration necessary; included in GitHub repositories
• Ability to create Pull Requests with detailed context (release notes, change log, commit links)
• Highly configurable (change update frequency, alerts, branching)
For more information, check out: general overview, Dependabot FAQ and resources, and this walkthrough article
SonarQube is a well-established developer tool for bug-fixes and code smells. It can also perform powerful code security scanning. Coming soon, SonarQube Enterprise will be integrated into the backbone as the preferred SAST tool.
SonarQube can record metrics history and provides evolution graphs. SonarQube provides fully automated analysis and integration with Maven, Ant, Gradle, MSBuild and continuous integration tools (Atlassian Bamboo, Jenkins, Hudson, etc.).
DevSecOps On Demand - Home (sharepoint.com)
Simple consistent scalable framework and workflow enabling teams to go fast and collaborate cross creation centers. Embedding security practices throughout the lifecycle lowers risk exposure for .
Enable our teams to be Agile and support our business partners delivering greater value to our patients. Attract and retain top digital talent via an improved colleague experience.
Security Objectives: Harder to Hack, Detect Attacks Fast, Respond Decisively
DevSecOps Vision & Value
Simple consistent scalable framework and workflow enabling teams to go fast and collaborate cross creation centers.
Embedding security practices throughout the lifecycle lowers risk exposure for .
Enable our teams to be Agile and support our business partners delivering greater value to our patients.
Enable our teams to be empowered and autonomous.
Attract and retain top digital talent via an improved colleague experience.
Overview
A version control system, or VCS, tracks the history of changes as people and teams collaborate on projects together. As the project evolves, teams can run tests, fix bugs, and contribute new code with the confidence that any version can be recovered at any time. Developers can review project history to find out:
• Which changes were made?
• Who made the changes?
• When were the changes made?
• Why were changes needed?
Git is an example of a distributed version control system (DVCS) commonly used for open source and commercial software development. DVCSs allow full access to every file, branch, and iteration of a project, and allows every user access to a full and self-contained history of all changes. Unlike once popular centralized version control systems, DVCSs like Git don’t need a constant connection to a central repository. Developers can work anywhere and collaborate asynchronously from any time zone.
Without version control, team members are subject to redundant tasks, slower timelines, and multiple copies of a single project. To eliminate unnecessary work, Git and other VCSs give each contributor a unified and consistent view of a project, surfacing work that’s already in progress. Seeing a transparent history of changes, who made them, and how they contribute to the development of a project helps team members stay aligned while working independently.
GitHub is a distributed version control system (DVCS) allowing users to maintain local and centralized repositories and feature branches. It is the source control management (SCM) solution that will be used across all teams.
LET'S ONBOARD YOU
Prepare your team
We are setting up dedicated GitHub organizations under enterprise account. We want to follow structure and give teams the privileges to setup and manager their own space, empowering the DevOps culture across .
Access to repositories is controlled through GitHub Teams. Before you start using GitHub in your organization we encourage you to do the following
To get started with GitHub your team members must be invited in a GitHub organization and be given the proper access rights. We have an onboarding process with the following steps:
• Fill in the onboarding form (onboarding form). Please answer all the questions and provide some information about your team. Do not forget to add the names of a few team members so we can contact you.
• VC/CI Contact. One of the VC/CI team members will contact you and will schedule a call to get you onboarded.
• In this meeting, we will:
• Walk you through our approach around using GitHub enterprise
• Discuss our policies and standards
• Invite the owners/representatives of your team in a GitHub organization
• Start creating the first GitHub teams for your group.
After the meeting the organization owners will be able to invite members, create more teams and start creating/migrating repositories
• Prepare for the meeting. To speed up the onboarding process we would like you to perform the following actions before the meeting:
• Read our documentation
• Protecting Code. Did you know that it is one of our competitive advantages over other companies? If we want to win the Digital race, we need to protect it. Here is how.
Guardrails and Best Practices
On-Boarding Steps
•
• Select the users that will be the GitHub owners for your organization. GitHub owners have advanced access rights in a GitHub org (create and manage teams, invite users, create and manage repositories, apply policies, etc.). We need at least one member to grant this privilege during the call.
• Think about the structure of your teams. You will find some hints in the attached documentation.
• Create GitHub accounts (if you don’t have) and make sure that the following policies are followed:
• Add a verified email to your account.
• Enable 2FA authentication.
If you want to learn more before your onboarding call, we have a list of useful links with training material:
• GitHub training material and Udemy courses
Work and Test Management Home - Work and Test Management - Confluence (.com)
Welcome to the Work and Test Management (WTM) Confluence page! In addition to the Triage team, and your work with the Work and Test Management Team - this page is to serve as a reference for any questions you and your team might have regarding the tools under WTM's purview as well as any of the associate guard rails and best practices associated with the WTM process.
JIRA
Jira Software provides scrum and kanban boards out-of-the-box. Boards are task management hubs, where tasks are mapped to customizable workflows. Boards provide transparency across teamwork and visibility into the status of every work item.
Confluence
Confluence is a team workspace where knowledge and collaboration meet. Dynamic pages give your team a place to create, capture, and collaborate on any project or idea. Spaces help your team structure, organize, and share work, so every team member has visibility into institutional knowledge and access to the information they need to do their best work.
Tx3 VERA
Vera is an enterprise data security and information rights management platform that provides encryption and tracks and controls digital information shared across users, devices, applications, and platforms.
Tricentis qTest
Tricentis qTest helps unify, manage, and rapidly scale testing across the enterprise, so teams can collaborate to ship faster with less risk. qTest is a test management tool that allows developers visibility into ongoing test suites and cases and allows integration with a number of different tools to help automate the testing process.
MIRO
Miro is the online collaborative whiteboard platform that enables distributed teams to work effectively together, from brainstorming with digital sticky notes to planning and managing agile workflows.
ALM QC
HP ALM (Application Life Cycle Management) is a web based tool that helps organizations to manage the application lifecycle right from project planning, requirements gathering, until Testing & deployment, which otherwise is a time-consuming task.
GitHub Migrations - GitHub at - Confluence
You want to move your software source control to GitHub? You're in the right place. We are very happy to work with you to migrate your software projects and teams. There are so many benefits to bringing source control for under a shared service.
This section includes information to guide teams through migrations or transfers. There is a mix of process documentation and project documentation. We can share learning and make it easier for everyone
Who is this for: You may be an individual contributor, a team lead, or a product owner.
Who we are: The Source Code Management Team, also known as The GitHub at Team. You can contact us through the GitHub Consultancy.
Definitions
Migration means you're moving from outside of GitHub (Bitbucket, Gitlab or other). This could mean moving people from SVN to Git (and the required training/onboarding) and changing your workflows/automations.
Transfer means you're moving from a location on GitHub.com to 's GitHub Enterprise. The level of effort for a transfer is lower than a migration. GitHub takes care of the move elegantly.
Prep ahead of time
If you are starting to think of a migration, read through these questions in preparation before meeting with us. If you send us this information before we meet, we'll be able to review your situation before we meet and make better use of your time.
The Migration or Transfer Process
When you contact us, the GitHub team will help you plan out, initiate, and complete your migration step by step. In the evaluation phase, we will uncover any requirements and potential blockers. From there we can get the right people involved and plan out the migration.
We're working on the process in partnership with each user and team. Keep the feedback coming about how we can make things better.
1. Evaluate current tools and processes
• Collect any pain points that explain WHY you're moving away from your current solution.
• What impact will there be on people, automations, project management?
• What changes or differences are there going to be in the day-to-day workflow?
• If you're coming from another VCS (version control system) what are the difference which have an impact?
2. Identify strategic decisions that have to be made.
• Collect scenarios and use cases you need to service, and phrase them as questions.
• Weighing the business requirements and technical constraints arising from Evaluation, decide the best solution for each question.
• Also document alternatives considered, eliminated, and why.
• Begin to evaluate solutions to meet requirements. What is the decided approach?
3. Plan the schedule for the when you need to move
• Depending on the number of repositories and the common issues, chunk similar problems together.
• Plan to test and iterate on migration scripts.
• Get dates in the calendar and start communicating wider!
4. Begin onboarding as soon as the migration planning starts
• Get teams started on appropriate training
• Get teams access (general welcome mat for GitHub coming soon!)
5. Initiate the migration
• Continue testing and iterating on migration scripts
• Keep communication flowing
• Celebrate the move and tell people about it!
• Document any learning to share for others.
Transfer - Moving GitHub to GitHub
You involve the org owner from where you are moving.
The migration can only be conducted by org owner
Questions to ask about a migration or transfer
• What user need or business goal are you trying to achieve through the migration or transfer?
o What does success look like?
• Where are you migrating from and to?
o Off-site, not on GitHub, or is it already on GitHub?
o Where should the repos be migrated to? An existing org or is there cause for a new organisation?
• Timeframe
o What is the target migration date.
o Any immovable hard deadlines? Launches?
o What is testing and release management like?
o Working back, how soon can we start with evaluation? This can be done asynchronous.
• Executive sponsors
o Include information about their Role, Team, Department, and pillar within .
• Project Lead or leads.
o This should include the future organisation owners if they are involved.
• You need an organisation owner involved in the migration.
o Will you need to add an organisation owner who represents the migrating repositories and projects? Or will an existing organisation owner play a role?
o Organisation owners have great power, but it comes at a cost. Please consider the Responsibilities of Organization Owners.
• Scale of impact on ongoing projects
o Depending on the origin of the source, it can greatly impact what people need to do and any integrations and automation.
If you're coming from a centralised system, do you need to migrate the history?
o People: What is the skill level and experience of the team with GitHub?
o Automation: What build systems and automation are in place?
Additional technical details to consider
• Any AWS services they need to access.
• If it isn’t an API call but an instance connection we need the full details (IP, ports, hostname, security groups)
• Full domain names of any online services they need to connect to via port 80 or 443
• CIDR blocks (Classless Inter-Domain Routing) and port numbers for any other connections they need to make
• This applies if it is on network or off. They should think about package repos, other code repos, api calls, deployment targets, AWS resources any connection it makes.
Digital Workplace Portal (sharepoint.com)
Change an Existing Solution
Retire a Solution
Or go straight to the SDLC Elements Tables (for inflight projects), SOP WTSO-0906 (SDLC SOP), WTSO-0839 (Change Management SOP), WTSO-0908 (Retire Solution SOP) or the Approval Matrix for each Element.
See the subject areas below for additional guidance on specific areas of the SDLC Lifecycle
Pre-requisites
Overview of Items & Tasks to Complete Prior to Developing Your Plan
Process Documentation
An Overview of SDLC Process Documentation, Templates and Supporting Procedures
Agile SDLC - Leveraging Agile Delivery Methodologies
An Overview of Delivery Methodologies that can be Used to Meet the Elements of the SDLC
Training
Links to SDLC Process & Related Training Courses
Security in SDLC
Delivering a secure solution is vital. Guidance on the security deliverables in an SDLC project
Data Migration
Performing Data Migration? Guidance can be found here.
Verification Strategy Recommendations
Guidance on Verification Script Writing, Execution, Deviation Management and Verification Summary
Solution Retirement
An Overview of the SDLC Retirement Phase Process
Supplier Assessment
Guidance on the Supplier Assessment Processes (SCA, SVA, Security) and When to Use Them
Tools
Guidance on Tools that Can be Used to Deliver SDLC Elements
Example Use Cases
There are multiple ways to meet the requirements of the SDLC. Here are some examples of how Digital project teams achieved thi...
Citizen Development
Overview and Guidance of Citizen Development at
Validation Guidance
Additional guidance on validation approach/strategy
Requirements Risk Assessment
Guidance on Performing Solution Risk Assessments
Privacy By Design (Under Construction)
Guidance on building controls into systems to ensure compliance with privacy regulations
DevSecOps Toolchain
A DevSecOps toolchain includes the tools and technology that enable development and operations teams to collaborate across the entire software lifecycle. It tackles key DevOps fundamentals including continuous integration, continuous delivery, automation, and collaboration. DevOps, while emphasizing collaboration and integration also looks to automation tools that can leverage an increasingly programmable and dynamic infrastructure from a lifecycle perspective. Version control and automating code deployments are two of the most impactful common tools but there are many more, including configuration management, ticketing systems, monitoring and provisioning.
For more information, please reach out to the DevSecOps Transformation Team
Workflow Management (JIRA)
Workflows in Jira model your organizational processes and allow you to progress tasks in the system.
Jira has its own workflows built-in. These include:
• Task management: The simplest possible workflow, to get tasks done as soon as possible.
• Project management: A very slightly more complex workflow, which includes an “In Progress” status to better mark work on the task.
• Process management: A structure that comes with multiple statuses and resolutions, which begins to reflect the complexity of business and development processes
Jira can be used for documenting SDLC elements such as User and Functional Requirements. There are two instances of Jira in use at today, Jira Data Center and Jira Cloud. Jira Data Center is validated for GxP SDLC solutions ONLY when it is used in conjunction with Testing and Approval tools that have also been validated for GxP SDLC solutions. Jira Cloud is not validated for GxP SDLC solutions.
Test Management
Test management tools are used to organize, store and report on test cases and test scripts. In agile SDLC projects, test management software can be a powerful tool in prioritizing your tests, document results for regulatory compliance, reducing the duplication of data and improving the coverage of manual tests. Examples of test management tools used within Digital are:
Testrail (Idera) - Centralized test management, integrates with bug trackers and automated testing tools, integrates with Jira, Metrics and Reports, SaaS solution
qTest (Tricentis) - Centralized test management, integrates with Tx3 VERA (eApproval), natively integrates with most automated testing tools, integrates with Jira, SaaS solution, validated for GxP SDLC solutions
Application Lifecycle Management/Quality Center/ALM-QC (MicroFocus) - Quality management software, requirements management, test management, no Jira integration, server-based solution, validated for GxP SDLC solutions
Automated Testing/Test Runner
Testing is one of the most critical processes of the Software Development Lifecycle (SDLC). It helps companies to perform a comprehensive assessment of software and ensure that their product fulfills the client’s needs.
During this phase, QA and testing teams may find bugs/defects which they communicate to developers. The development team fixes the bug and refer back to QA for a re-test. This process continues until the software is bug-free, stable, and working according to the business needs of that system.
There are several types of testing during the test phase, including unit testing, system testing, and user acceptance testing (UAT). Below are examples of automated testing tools used in the Digital environment:
pytest (open source) - Python-based test writer, requires Python programming knowledge, scalable, integrates with test management software
Tosca (Tricentis) - Automates end-to-end testing for software applications, Mode-Based Test Automation, Support for SAP UIs & Technologies
Selenium (open source) - Automated testing framework used to test web applications across different browsers and platforms. You can use multiple programming languages like Java, C#, Python etc to create Selenium Test Scripts
PHPUnit (open source) - A unit testing framework designed for unit testing solutions developed using the PHP (Hypertext Preprocessor) programming language.
Security
In a secure SDLC, security is integrated throughout the development and delivery cycle and implemented in every stage. The secure SDLC is designed so that security issues are detected and remediated as early as possible, rather than relegating security testing to the later stages of development when issues are significantly more expensive and time-consuming to address.
Achieving a secure SDLC requires organizations to adopt an updated set of security practices and processes. This new approach addresses every aspect of the SDLC to ensure security is integrated into the entire development process and to speed up detection and remediation. This includes updating processes so that security is tested early and often, integrating automated application security testing tools throughout the SDLC and ensuring that security, DevOps, and development teams are working together toward the shared goal of secure development and delivery.
To meet the requirements of the Common Requirements Set, the following tools are being introduced to support application security testing:
• Software Composition Analysis (SCA) Tools – Encompasses the monitoring and managing of license compliance and security vulnerabilities in the open source components the code depends on.
o Dependabot (GitHub) - An SCA tool, part of GitHub suite, that checks code dependency files for outdated requirements and opens individual pull requests for any it finds
• Static Application Security Testing (SAST) Tools - Helps in identifying vulnerabilities in proprietary developed code to detect and remediate potential vulnerabilities early in the DevOps cycle.
o SonarQube (SonarSource) - Performs continuous inspection of code quality to perform automatic reviews with static analysis of code to detect bugs, code smells on 20+ programming languages
• Dynamic and Interactive Application Security Testing (DAST and IAST) Tools – Tests the running application’s exposed interfaces, looking for vulnerabilities and flaws.
For more information, please reach out to the DevSecOps Transformation Team
eSignature/eApproval
VERA (Tricentis) - has been validated for use for electronic approval/signature in agile projects. It is capable of pre- and post-test execution review and approval capabilities, to 21 CFR Part 11 compliant electronic signatures captured at the data level. VERA integrates with Tricentis qTest and ALM-QC.
DocuSign is a SaaS-based eSignature solution used primarily for signing legally-binding documents. Digital does offer a 21 CFR Part 11 validated instance of DocuSign for approval of GxP documentation. Please refer to Digital on Demand for more information.
Use of Software Validation Tools
Software tools that assist in the validation process (i.e. requirements management, testing software, etc.) shall be assessed for adequacy and be appropriately qualified. Software tools do not automatically inherit the risk of the system(s) or process(es) they support. Hence, it may not be necessary to apply GMP-level rigor to standard tools that are highly reliable and considered to be the most appropriate and effective means of maintaining and improving quality.
The level and rigor of specification and verification applied to business/user applications shall be based on risk, complexity and novelty and the integrity of the records generated by the software tools shall be assured.