New Hotfix Process added

_pages/Center-of-Excellence.md

@@ -1,18 +1,18 @@
-###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
 - Review, approve, disapprove, and prioritize changes to configuration items within T&I’s enterprise platforms and commit resources to the implementation of approved changes
 - 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,15 +185,15 @@ 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.  
 
 The COE Facilitator is responsible for maintaining calendar invites, reserving rooms, setting up WebEx or conference bridges, taking requests for agenda time, recording meeting attendance, and documenting / posting meeting minutes.  The COE Facilitator will prepare an agenda for each COE meeting.  Items to be considered for a COE meeting must be submitted to the Facilitator no later than one hour prior to the meeting.  See request agenda request form here.  
 
 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<br>
 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**
 

_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)

_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)
+![Deployment](/img/Deployment-Pipeline.png)

_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. 
+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.
+

_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
 

_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,15 +35,15 @@ 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. 
 
 When working with Salesforce sharing it is always best to use the most global sharing mechanisms first, then move to the more granular controls. As you move to the more granular sharing controls you need to be more aware of performance considerations. 
 
 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. 
+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. 

_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.
 

_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. 
 

_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/)