diff --git a/_pages/Center-of-Excellence.md b/_pages/Center-of-Excellence.md index 488ed90..33e273e 100644 --- a/_pages/Center-of-Excellence.md +++ b/_pages/Center-of-Excellence.md @@ -1,10 +1,10 @@ -###Center of Excellence +# Center of Excellence -###Overview +## Overview This document is the charter for the Consumer Financial Protection Bureau (CFPB) Office of the Chief Information Officer (OCIO) Enterprise Platforms (EP) Center of Excellence (COE) (hereafter referred to as “COE”), and as such formalizes the responsibilities, process, and authority of this body. -###Authority +## Authority This document includes the authority and responsibilities of the COE and its members who will abide by the practices set forth in this charter. This charter authorizes the COE to perform the following: - Review, approve, disapprove, and prioritize development initiatives within T&I’s enterprise platforms and commit resources to the development of approved initiatives @@ -12,7 +12,7 @@ This document includes the authority and responsibilities of the COE and its mem - Manage T&I’s enterprise platforms application development, operations and maintenance processes - Ensure the technical quality of all software deployed to T&I’s enterprise platforms and of services integrated with these platforms -###Purpose +## Purpose This document establishes the authority, membership, roles, and administrative procedures for the Center of Excellence (COE). The COE is a decision-making body that provides oversight and management of CFPB’s enterprise platforms. The COE is the official mechanism for controlling the strategic direction of CFPB’s enterprise cloud, web-enabled and/or on-premise platforms and tools, such as Salesforce.com and Box.com. The COE serves the following primary functions: - **Strategic Platform Roadmap and Standards** - for driving the technical direction and standards of the Bureau’s platforms in support of enabling business and process automation @@ -21,7 +21,7 @@ This document establishes the authority, membership, roles, and administrative p - **Go Live Review** - for completed systems and releases prior to production deployment - **Change Request (CR) Review** - for changes to production applications / features or approved plans / processes -###Responsibilities +## Responsibilities The COE is responsible for making project-level tactical decisions for applications deployed to the Bureau’s Salesforce and Box platforms that support the strategic direction established by the Chief Information Officer in line with the Bureau’s Strategic Plan. @@ -185,7 +185,7 @@ Membership of the COE consists of the following voting and non-voting member rol *Note: Only government employees may be voting members. In the event that a role above is being filled by a contractor, the voting check mark in the table above is instead a recommendation for those roles which are considered to have especially appropriate input to the type of vote indicated. -###COE Administration +## COE Administration Normal COE meetings will be held on a weekly basis. If there are no items for review, COE meetings will be canceled at the discretion of the COE Chair. Additional meetings may also be scheduled at the Chair’s discretion to handle a high volume of agenda items. @@ -193,7 +193,7 @@ The COE Facilitator is responsible for maintaining calendar invites, reserving r Links to the COE agendas and meeting minutes can be accessed through the T&I Enterprise Platforms team Google Documents collection. -###Decisions +## Decisions - **New Solution Review** New solution concepts will be introduced at COE meetings by Platform Business Analysts (BA) who will be expected to present high-level requirements and the analysis conducted (Project Detail, Fit Gap Analysis) to make a platform decision to the COE. After each new solution concept is discussed, a vote will be taken to **approve, defer, or disapprove** the proposed item. The EP Program team will work with the business line(s) involved and T&I PMO to review scheduling, resources, and budget for the new solution request. @@ -230,7 +230,7 @@ Links to the COE agendas and meeting minutes can be accessed through the T&I Ent ###Changes to the Charter Any proposed changes to this COE Charter may be reviewed and approved as a standard CR. This charter will be reviewed annually or as required. Any necessary revisions will be made and tracked via the charter revision history. -###Appendix A +## Appendix A **Acronym List** @@ -241,7 +241,7 @@ CR - Change Request
SwAG - Software Advisory Group - The SwAG is composed of a diversified team of architects (technical, solution, product-specific) with expertise in technologies the Bureau supports T&I - Technology & Innovation -###Appendix B +## Appendix B **COE Membership** diff --git a/_pages/Deployment-Hotfix.md b/_pages/Deployment-Hotfix.md new file mode 100644 index 0000000..6319d79 --- /dev/null +++ b/_pages/Deployment-Hotfix.md @@ -0,0 +1,20 @@ +# Deployment Hotfix + +## Process Overview + +Hotfix Relase: A release to production that includes only business-critical fixes and/or additions to address known bugs. Hotfixes are not considered regular releases. + +O&M Release: A coordinated, scheduled release to production that includes fixes to all non-critical bugs that have been resolved by the Project Teams. + +Product Releases: A scheduled release to production that includes net-new functionality. The functionality included within releases of this type is based on prioritization determinations made by the Change Control Board. + +Hotfix Environment: The hotfix environment is where project teams will deploy changes for the same validation before moving the change to Production. Hotfix Release will use hotfix environment. All validation and testing should be performed in this environment so that platforms team will give the approval to move changes to the production environment. + + +## Deploying to Production +In order to deploy a Hotfix release to production, the project team must first deploy their code and configuration to the Hotfix environment. The reason that the team must first deploy to these lower environment is so that we can verify that your application works as expected, and does not experience any complications during deployment. + + +Below you will find a Hotfix production release process diagram. + +![Deployment](/img/Deployment-Hotfix.png) diff --git a/_pages/Deployment-Pipeline.md b/_pages/Deployment-Pipeline.md index 5a527ae..0e97f47 100644 --- a/_pages/Deployment-Pipeline.md +++ b/_pages/Deployment-Pipeline.md @@ -1,19 +1,19 @@ -###Deployment Pipeline +# Deployment Pipeline -####Process Overview +## Process Overview The goal of the release management process is to create a process that defines 1. The environments necessary to enable multiple project teams to concurrently develop applications on the Salesforce platform 1. The mechanism that enables project teams to easily move Salesforce configuration and code from one environment to another 1. The process that all Salesforce project teams follow to deploy code and configuration from one environment to another in a repeatable fashion to ensure business continuity while reducing the total time of deployment of applications to production. -####Development Models +## Development Models There are two different models that a project team can use while developing their applications. 1. **Centralized Development Model** - A centralized development model is a development structure in which all team members configure and develop Salesforce applications in a single environment. This structure is typically used when there are a small number of developers working on separate capabilities that do not conflict with each other. 1. **Distributed Development Model** - A distributed development model is a development structure in which each developer has their own dedicated Salesforce sandbox where they develop application features. They can perform configuration and code changes in their dedicated environment. When they have completed a specific feature, that feature is then deployed to a master team development environment that is typically controlled by a project lead. This allows many developers to function independently without impacting other team members. This structure is typically used for larger development teams. -####Salesforce Environments +## Salesforce Environments The salesforce environments used for Salesforce releases are broken up into categories: **Project Environments** - Project environments are Salesforce sandbox environments that are dedicated to a single project team. The project team has full access to the environments and does not share the environments with any other project team. The project team members manage all releases among all of their environments and choose the level of access each member has to each of their environments. @@ -40,10 +40,10 @@ Platform environments consist of the the following environments: 1. **Production** - This is the live environment where users are actively using the system. -####Deploying to Production +## Deploying to Production In order to deploy a release to production, the project team must first deploy their code and configuration to the different platform environments described above. The reason that the team must first deploy to these lower environments is so that we can verify that your application works as expected, does not conflict with other teams environments, and does not experience any complications during deployment. Below you will find a diagram of the environments described above depicting the flow a deployment must go through in order to be deployed to production. -![Deployment](/img/Deployment-Pipeline.png) \ No newline at end of file +![Deployment](/img/Deployment-Pipeline.png) diff --git a/_pages/Exception-Handling.md b/_pages/Exception-Handling.md index e1318b9..ad2b1da 100644 --- a/_pages/Exception-Handling.md +++ b/_pages/Exception-Handling.md @@ -110,4 +110,11 @@ public with sharing class OrderController } ``` -If you find that you need to create exceptions that are multiple levels deep, then it may be a good time to start thinking about creating a custom exception class so that your exceptions are more easily traceable when trying to debug. \ No newline at end of file +If you find that you need to create exceptions that are multiple levels deep, then it may be a good time to start thinking about creating a custom exception class so that your exceptions are more easily traceable when trying to debug. + +### Set Recipients of Email Notifications for Unhandled Apex Exceptions + +Configure email addresses that receive emails when your Apex code encounters unhandled exceptions. Previously, these emails were sent only to the developer who’d last modified a failing class or trigger. From Winter 2016 Salesforce release you can also notify users of your Salesforce org and arbitrary email addresses. + +Unhandled exception emails are sent by default to the developer specified in the LastModifiedBy field on the failing class or trigger. In addition, you can have emails sent to users of your Salesforce org and to arbitrary email addresses. To set up these email notifications, from Setup, enter Apex Exception Email in the Quick Find box, then select Apex Exception Email. You can also configure Apex exception emails using the Tooling API object ApexEmailNotification. + diff --git a/_pages/Guiding-Principles.md b/_pages/Guiding-Principles.md index 4f63878..4703a15 100644 --- a/_pages/Guiding-Principles.md +++ b/_pages/Guiding-Principles.md @@ -1,4 +1,4 @@ -###Guiding Principles +# Guiding Principles Enterprise Platforms has established a set of guiding principles to inspire our day-to-day activities and drive the behaviors that will help us truly achieve our mission and vision diff --git a/_pages/Record-Level-Sharing.md b/_pages/Record-Level-Sharing.md index 343f78d..34129a3 100644 --- a/_pages/Record-Level-Sharing.md +++ b/_pages/Record-Level-Sharing.md @@ -1,4 +1,4 @@ -###Sharing & Security +# Sharing & Security There are many different mechanisms in which access to Salesforce is controlled. It is easiest to think of security in Salesforce broken up into the following 3 different categories: @@ -8,7 +8,7 @@ There are many different mechanisms in which access to Salesforce is controlled. 1. **System & Application Level Access** – System and application level access is access users are granted to perform specific actions across the Salesforce application. There are many different actions a user can perform that can be controlled such as user creation, ability to export data, ability to modify setup objects, etc. These permissions are controlled by Profiles and Permission Sets. -###Profiles & Permission Sets +## Profiles & Permission Sets As mentioned above Profiles & Permission Sets control the object level access and System & Application level access for users. You can pretty much do the same thing with Profiles and Permission Sets except for that a user can only have one profile where you can assign multiple permission sets to a user or profile. @@ -35,7 +35,7 @@ The permission sets would be assigned on a user-by-user basis based on the appli -###Salesforce Sharing +## Salesforce Sharing Salesforce sharing controls what records users have access to view and edit. Keep in mind that since the profile and permission sets control object level access, if a user doesn’t have access to a particular object, then even if sharing allows them to view or edit records within that object, they will not have access to those records since they don’t have access to the entire object through profiles or permission sets. @@ -43,7 +43,7 @@ When working with Salesforce sharing it is always best to use the most global sh The following are the Salesforce sharing controls available. -###Organization-Wide Defaults +## Organization-Wide Defaults Organization-Wide defaults are the highest level and most restrictive sharing controls available on the platform. These settings control the visibility of records on a global scale for objects. These settings are set on an object by object basis. The following are the available options: @@ -60,7 +60,7 @@ Public Read Only is the second most restrictive organization-wide default and is ***Private*** Private is the most restrictive organization-wide default and is available for most standard and all custom objects. This setting restricts every user from viewing or editing records within the objects that are set to “Private” unless they are granted “view” or “edit” access through other sharing settings. -###Criteria Based Sharing (Sharing Rules) +## Criteria Based Sharing (Sharing Rules) Criteria based sharing is rule or owner based sharing that grants read or read/write access for a set of records to specific groups of users. Criteria Based Sharing is next level of sharing controls below organization wide defaults. There are two types of rules that can be created. @@ -71,7 +71,7 @@ Rules based on record owner grant access to users in specific roles or groups to ***Based On Criteria*** Criteria based rules grant access to users in specific roles or groups to records that match specific criteria on the records within the object. -###Role Based Sharing +## Role Based Sharing Roles are hierarchal groupings of users within a Salesforce org. Role based sharing propagates the access to records that users have to users up the role hierarchy. For example: If the following role hierarchy exists: @@ -86,14 +86,14 @@ Then anyone that is a member of the “Sales VP” role will inherit the access -###Manual Sharing +## Manual Sharing Manual sharing is the most granular and least performing of all sharing mechanisms within Salesforce. Care must be taken when using manual sharing as too many manual sharing rules on any single object can cause a delay in response time when viewing records on that object. Manual sharing allows the owner of a record to manually grant (share) read or read/write access to a record to another user, group, or role. Manual shares can also be created programmatically using apex or apex triggers. Use caution while programmatically creating manual shares via apex as you can easily cause performance degradation if you are adding a large number of shares to a single object. -###Territory Based Sharing (Territory Management) +## Territory Based Sharing (Territory Management) Territory Management is a larger functionality in Salesforce that allows for creating territory groupings. Users and Accounts can then be assigned as members of a territory. Once a user has been added to a territory the user then is granted access to that account. You have the ability to specify for each territory is the users should gain read or read/write access to the account records. Additionally you can also choose is the users granted access to the accounts are granted access to related opportunities and/or cases to those accounts. @@ -108,7 +108,7 @@ For more information about territory management see: -###Special Permissions That Affect Sharing +## Special Permissions That Affect Sharing There are special permissions that can be set via profiles and permission sets that can override the Salesforce sharing settings. These permission exist in two types: @@ -119,4 +119,4 @@ Under the system permissions you will find the permissions “view all data” a Be very careful when setting this permission, as this permission will open up access to all of your data to a single user. Even if a field is set as read-only on the object profile permissions, the user will still have full access to the object as well. ***Object Level*** -In addition to the ability to grant global read or edit access to all records across all objects, you also can set read or edit access for all records for only a single object. At the object level if you set the permissions “view all” or “modify all” then all users in the profile or permission set will be able to view and/or edit all records within that object regardless of the sharing settings. \ No newline at end of file +In addition to the ability to grant global read or edit access to all records across all objects, you also can set read or edit access for all records for only a single object. At the object level if you set the permissions “view all” or “modify all” then all users in the profile or permission set will be able to view and/or edit all records within that object regardless of the sharing settings. diff --git a/_pages/Salesforce-Naming-Conventions.md b/_pages/Salesforce-Naming-Conventions.md index 76c87a6..1b41331 100644 --- a/_pages/Salesforce-Naming-Conventions.md +++ b/_pages/Salesforce-Naming-Conventions.md @@ -1,4 +1,4 @@ -##Salesforce Naming Conventions +# Salesforce Naming Conventions Naming conventions make the application easier to read and maintain. The naming standards documented here cover customization and configuration areas of salesforce. Regardless of the context in which names are used, Names should be descriptive, concrete, and specific rather than general. Having a generalized name such as ProductLine can have different semantics depending upon the context. It’s better to use something the business identifies with and that will not create a potential conflict with other applications; e.g., ReverseMortgage. diff --git a/_pages/Testing-&-Debugging.md b/_pages/Testing-&-Debugging.md index e381a15..ac56c95 100644 --- a/_pages/Testing-&-Debugging.md +++ b/_pages/Testing-&-Debugging.md @@ -1,4 +1,4 @@ -###Effective Testing and Debugging +# Effective Testing and Debugging - [Writing good tests](/_pages/Writing-good-tests.md) - [Unit testing](/_pages/Unit-testing.md) @@ -7,7 +7,7 @@ - 508/WCAG - More to come - [Top 10 Best Practices](/_pages/Top-10-Best-Practices.md) -####Testing +## Testing (NOTE: http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_testing_best_practices.htm) @@ -51,7 +51,7 @@ The following principles apply to unit testing Apex code 16. Do not write test classes merely to get code coverage. It is much more effective to write the test code to cover specific business cases. You will find that if you use this method you will cover much more code, much faster than just writing test code to get coverage only. Additionally this will help ensure that you are meeting the business requirements in addition to testing for bugs. -####Debugging +## Debugging Unlike traditional languages such as Java, C++, and C#, Apex and Visualforce can be quite cumbersome and time consuming when trying to debug. You don’t have the luxury of being able to step through the code during runtime. diff --git a/_pages/Top-10-Best-Practices.md b/_pages/Top-10-Best-Practices.md index 2329c43..9a2d577 100644 --- a/_pages/Top-10-Best-Practices.md +++ b/_pages/Top-10-Best-Practices.md @@ -1,5 +1,5 @@ -#Summary: Top 10 Best Practices (in no order) +# Summary: Top 10 Best Practices (in no order) (Source: http://blog.force365.com/2014/09/19/apex-unit-test-best-practice/) diff --git a/_pages/Visualsource-Pages.md b/_pages/Visualsource-Pages.md index bcafaac..f11b787 100644 --- a/_pages/Visualsource-Pages.md +++ b/_pages/Visualsource-Pages.md @@ -1,4 +1,4 @@ -##Visualforce Page Best Practices +# Visualforce Page Best Practices Just because you can, doesn’t mean you should! Before going down the customization route make sure you properly evaluate the pros and cons of creating custom pages. This is especially true when creating custom pages to override standard functionality. When overriding standard functionality you lose the advantage gained of new features in future releases. If you do go down the customization route you must make sure you optimize the Visualforce pages you create for better performance in order to have a positive user experience. @@ -69,4 +69,4 @@ When deciding to use lightning or Visualforce, carefully consider each of the pr 1. Will the application be a standalone application, or can it be broken into multiple components? 1. Does the application need to be responsive and run on multiple device formats? 1. Will the application need to look and feel like the “Aloha” UI or the “Lightning Experience” UI? -1. Do our developers have strong JavaScript and CSS skills? Will there be considerable ramp up time if we choose to use lightning? \ No newline at end of file +1. Do our developers have strong JavaScript and CSS skills? Will there be considerable ramp up time if we choose to use lightning? diff --git a/_pages/mission-vision.md b/_pages/mission-vision.md index f4c40b5..62a19a2 100644 --- a/_pages/mission-vision.md +++ b/_pages/mission-vision.md @@ -1,9 +1,9 @@ -###Enterprise Platforms Mission & Vision +# Enterprise Platforms Mission & Vision -####Mission +## Mission To enable the success of our business partners in achieving their mission by leveraging the Bureau’s enterprise platforms to deliver comprehensive solutions in a cost-effective, efficient manner -####Vision +## Vision -Striving to be the Bureau’s leader in business enablement, innovation and delivery excellence \ No newline at end of file +Striving to be the Bureau’s leader in business enablement, innovation and delivery excellence diff --git a/_pages/roles-&-responsibilities.md b/_pages/roles-&-responsibilities.md index 331caf7..fd860a8 100644 --- a/_pages/roles-&-responsibilities.md +++ b/_pages/roles-&-responsibilities.md @@ -1,10 +1,13 @@ -###Platform Center of Excellence +# Roles and Responsibilities -####Objective + +## Platform Center of Excellence + +#### Objective To provide oversight and governance for the Bureau’s standard enterprise platforms. -####Roles +#### Roles - **COE Chair** – Presides over the Platform Center of Excellence - **Platform Program Management** – Participants from Enterprise Platforms execution and operational arms support strategic roadmap and prioritization discussions and decisions @@ -13,7 +16,7 @@ To provide oversight and governance for the Bureau’s standard enterprise plat - **Business Line Representatives** – Participants from various business divisions, such as CR and SEFL, engage in the COE to ensure platform goals are in alignment with CFPB’s business / mission goals; support decisions that impact individual applications - **COE Facilitator** – Facilitates COE and SwAG meetings, maintains technical guidelines documents, and COE Templates -####Responsibilities +#### Responsibilities - Sets and enforces all platform technical standards, guidelines and conventions - Reviews technical design, solution architecture, and object model for platform products/applications @@ -25,14 +28,14 @@ To provide oversight and governance for the Bureau’s standard enterprise plat - Reviews new concepts for fit and dispositioning on a particular enterprise platform - Publishes and manages platform target architectures, incl. common platform objects -####Decision Authority +#### Decision Authority - Dispositioning of concept requests for fit on particular enterprise platforms - Technical design approval - Platform release readiness approval - Escalation to the CIO for business-impacting concerns -####Key Interfaces +#### Key Interfaces - Engages closely with T&I PMO for gate reviews / approvals - Regular representation from EA, Data, and Cyber Security to support guidance and decisions @@ -40,17 +43,17 @@ To provide oversight and governance for the Bureau’s standard enterprise plat ### Platform Program & Services -####Objective +#### Objective To provide program oversight and consultative platform services to T&I’s business line customers. -####Roles +#### Roles - **Platform Program Manager** – Oversees platform services and functions offered to customers - **Platform Project Gov Leads** – Oversee platform-related projects and tasks; interface with business line customers and other T&I team members regularly; CORs for platform contracts; deliver platform procurement services - **Platform Business Analysts** – Engage with business lines customers to analysis new or enhancement requests to help determine high-level requirements, solution and LOE -####Responsibilities +#### Responsibilities - Provide platform consulting services: - **New Solution Review:** Discovery, Project Detail, Fit-Gap Analysis, PMO Project Request Form @@ -64,26 +67,26 @@ To provide program oversight and consultative platform services to T&I’s busi - Manage platform key performance indicators (KPIs) - Manage resource needs and fulfillment -####Key Interfaces +#### Key Interfaces - Engage with business line customers to validate business requirements and emerging needs - Present new concepts, requirements analysis and findings at the Platform COE meetings for guidance and approval - Engage closely with T&I PMO for platform-level business roadmap roll-up to T&I Roadmap -###Platform Support Operations +### Platform Support Operations -####Objectives +#### Objectives To ensure optimal performance and operations of the Bureau’s enterprise platforms. -####Roles +#### Roles - **Operations Lead** – Oversees O&M, Release Management, CI, DevOps; approves, holds or rejects releases; reviews and approves Release Management policy and procedural changes - **Platform Dev Team** - Centralized Agile dev team available for enterprise app dev and platform work - **O&M Team** – Centralized O&M team with expertise in platform technologies, provide Tier 1 and 2 support for platforms - **Release Team** – oversees deployment activities and transition from existing App Dev/O&M Teams; executes the physical moves of code and configuration to higher environments, including user acceptance test, integration, staging and production -####Responsibilities +#### Responsibilities - Maintenance and operations of enterprise platforms, including administration and preventative maintenance, and managing platform-level technical management backlog - Bug reporting, processing and tracking @@ -94,7 +97,7 @@ To ensure optimal performance and operations of the Bureau’s enterprise platfo - Develop testing strategy - Establish Change Control Process for enterprise platforms -####Key Interfaces +#### Key Interfaces - Engages closely with T&I Change Control Board for change request notifications, reviews, and approvals - Work closely with contractor dev teams to plan releases to production diff --git a/img/Deployment-Hotfix.png b/img/Deployment-Hotfix.png new file mode 100644 index 0000000..90058a5 Binary files /dev/null and b/img/Deployment-Hotfix.png differ