Thursday, September 20, 2018

JTD-DesignerSeries-8-ApplicationLifecycle-101


Let's set some context
We understand that on premise applications are mentioned as monoliths these days, and basic ALM cycle steps of [Design--> Development-->Build-->Deploy-->Release] though are same, but the frameworks & tools are very different with the ubiquitous advent of Agile, DevOps, Cloud & Mobile.

We also understand that no one likes to wait, automation is important for innovation, so DevOps is umbrella term that streamlines build & deploy phase with version controls like Git, Build frameworks like Maven & CI/CD tools like Jenkins, Artifactory, Ansible etc.
Let's shift gear by going into specific of DevOps in Salesforce ecosystem where it is all about Sandboxes & Orgs. Usually developers will work on their changes in Developer Sandbox, and use change sets, Ant Migration Tool to push their changes on other Sandboxes for Integration Testing, UAT & Production Releases. In this Org Based Approach of releases with multiple Change Sets ,Production environments becomes the source of truth after the release cycle & it gets quite cumbersome & error-prone to re-sync the production changes as developers have already began their next release.

With new Salesforce DX tools & Source Based Approach, Salesforce has pushed for practical DevOps and pushing their customers to integrate their Salesforce Orgs with version control & CI/CD tools. Professional Players like Gearset, Flosum, AutoRabit are further refining this approach by creating & implementing solutions using DX Tooling, Metadata API to further enhance customer experience.

Let's talk some Salesforce DX
Monolith developers are quite familiar with deployment build scripts languages like Ant, Maven and enterprise application teams develop the build process with these tools to enable CI/CD. Salesforce DX, based on Source Based Development, streamlines continuous development on lightning platform. Salesforce DX is based on 4 core tenets:
  • Team Collaboration: As developers work on features, release engineers have to validate collaborated build for release, and DX tooling along with version control provides consistency to the build process.
  • Open Prescriptive: DX prescribes source driven development but keep it quite open by allowing you to choose different VCS (Git, SVN) , Build frameworks (Jenkins, Travis).
  • Automated Delivery: It takes quite a bit of automation between feature development & release, and it is quite important to release often in an iterative cycle, so DX supports organizing artifacts in a package.
  • Build for Enterprise: DX helps developers create ephemeral orgs, and tooling has to support many enterprises by creating & destroying scratch orgs, package monitoring, so DX is designed to meet the scale of enterprise ecosystem.
DX is providing tools like SFDX CLI, Scratch Orgs, Unlocked Packages, IDEs & Text Editors with Plugins along with Sandboxes, Change Set approaches to enable Agile Delivery.

Salesforce DX Tooling
As developers we have to agree that a bit of design should always precede a development phase, and teams take different approaches of white boarding, design specs, prototyping and many other. A bit of design enables modularity & developers start spitting artifacts by creating projects. It is very important that developers working in an ecosystem / framework gets the same base structure to ensure consistency and with DX, and you can do that by using a CLI command [sfdx force:project:create -n geolocation].
Salesforce is Metadata Aware, which helps auto generate freebies but can spit out big files & a bit problematic from change management perspective. With DX, you still control how you break up the customizations but developers can use scratch orgs as their development environment which easily syncs with other programmatic artifacts of the project.

  • Salesforce DX Project: It contains local copy of related artifacts, app code or customization, and core assets required to synchronize source & metadata with the scratch orgs.
  • Scratch Orgs: It is a dedicated & configurable salesforce environments but are designed to be short lived and re-created based on project configuration.
  • Salesforce Command Line Interface: Developers with Heroku skills are quite used to CLI interface and SFDC CLI has combined capabilities from several APIs like Metadata API, Tooling API & provides a command interface to support build scripting functions.
  • Salesforce Extensions for VS Code: With DX tooling, Salesforce has provided plugins for VS code, with which developers get an Integrated Development Environment to develop on Lightning Platform.

Deploy with Unlocked Packages
While working as middleware consultant, I am quite used to deployment artifacts build as Jars which are pushed to servers in upstream environments like UAT, Production. In Salesforce ecosystem, we are working with metadata, and by definition packages are container that help you organize & deploy your metadata. Some of the advantages of packaging based development:
a) Packages allow you to iterate with versions by taking the snapshot of metadata tracked by a unique VersionID, and at any give time you can map the deployed artifacts to the installed version.
b) Unlocked packages specifically keep the design quite flexible by allowing you to add, update metadata even directly in Production environment, but it make sense to sync those changes back into Dev branch.

Comparing ChangeSets & Package Based Deployment
With ChangeSet, Org changes are moved between Sandboxes until they are pushed to production, but with Packages, code exist in version control & tested in Scratch Orgs until Dev complete stage, which is when they are packaged as a deployable artifact into upstream release environments.




Links & Reference
a) https://trailhead.salesforce.com/trails/sfdx_get_started

Monday, September 17, 2018

JTD-DesignerSeries-7-LightningComponents-101


Let's set some context
I am a developer but not a salesforce classic developer, not even a Front End Developer but most developers a feeling a bit of change. In my college days, we just talked about software developers, but then in industry, I started hearing .Net Developer, Java Developer, Web Developer, Middleware Developer, Database Developer etc, and quite a few like me started working as skill oriented consultant. These days, I would say that learning curve is quite steep, as you are expected to be a Full-Stack Developer, and every application being browser & mobile based, there is no escape from learning. So, Lightning Component is modern UI framework for Salesforce Applications, just like Angular incubated by Google & React by Facebook. It is mentioned in trail modules, & I must say as well, that it is quite important to improve your Javascript , if you are developing with lightning components.


Let's talk some Javascript
a) Javascript Engine, which is single threaded runtime, is standardized on ECMAScript and is part of browser application. JS Engine interprets Javascript code and it is essential to develop basic understanding of concepts like Execution Context, Lexical Environment Hoisting, Execution Stack, Callbacks etc.
b) Saying goes like this that everything in JS is Objects, and with Functions & advance pattern application, savvy Javascript developers have developed frameworks & libraries like JQuery and realize the power of Javascript programming, but it may be quite difficult to master Javascript as it is quite complex & weird. For eg: Global Execution Context creates Global Object (Window) & this variable by default.
c) Execution of a function creates a new execution context, and nested function calls are placed on the execution stack. Javascript engine runs a single execution context at a time, and scope chains are used by JS Engine to determine variable value by looking at outer reference when variable is not defined in the function context.
d) Asynchronous behavior in JE engine, which by the way is synchronous, is enabled with event queue and engine picks the event when the execution stack is empty.
e) I would say that keep learning how JS works under the hood along with using established lightning component patterns while developing on lightning platform.

A brief on Lightning Components
We should say that Lightning is like a branding as would have been with Classic, with Lightning keyword attached with Lightning Experience, Lightning Apps, Lightning Pages, Lightning Components, Lightning Data Service and so on.
Lightning Components, in its definition, is a UI framework for building dynamic responsive pages & apps on lightning platform. It is a modern framework like Angular that builds application as SPA rather than multiple pages like with Visualforce, and navigation is managed as state change rather than navigating to another page. Developers design Lightning Components by bundling component markup xml (sample.cmp), client side controller functions (sampleController.js), common functions as helper (sampleHelper.js), custom styles for component (sample.css), configurable design attributes (sample.design).
Designers usually create multiple fine grained components to build a reusable features that can be published as coarse-grained lightning components which can used in Lightning Experience, Lightning Apps and so on, an example may be Standard components like Path, Page Header, Record Detail.
Lightning components are client side framework technology which fetches data from the server by initiating a request from the browser using http stateless protocol to the server side apex controller classes annotated with @AuraEnabled and coupling is established with controller attribute in the component definition (aura:component controller="serverSideContollerClass"). Components communicate with each other using attributes & lightning events. Generally parents can pass the data to the child components using attributes & other communication is usually established by registering for an event & handler functions.
Generally, development shops are focused on building and customizing component libraries which is quite similar to SOA governance initiatives in large implementations with large Services Registries.

A brief on Lightning Design System (SLDS)
Enterprise Applications care a lot about standard look & feel, and Lightning Experience enables it for both Desktop & Mobile Apps with SLDS and provide consistent development experience for a many designers & developers in salesforce community. Four core tenants of Lightning Design System are clarity, efficiency, consistency & beauty.SLDS acts as a central repository of components, patterns & guidelines. As developers, the more you work with SLDS, the better you get at picking components, but they are categorized as simple components like buttons, complex components like dropdown menu, structure components like Button Groups, feature or experience components like Sales Path. SLDS eases layout design by providing gird based FlexBox Containers like slds-grid. SLDS grids offers features like automatic sizing on different device sizes, utility sizing classes, support for edge scenarios with single purpose utility classes like slds-has-flexi-truncate.

A brief on Lightning Data Service (LDS)
By now, we understood that Lightning Platform supports component based UI layer, with multiple, nested components in a single view. In Lightning component basics, we learned that components communicate with each other through events & attributes. Though as each component is developed separately & can exists on its own, it makes its own copy of data & changes made in one component is not reflected in other components.
LDS address these problems by allowing component developers with simple configuration (force:recordData) and let platform create a unifying layer to control data access for all these components with configuration. Some of the advantages of this integration layer is improved performance with cacheing, data security by proxying component access to server data & other platform services & validations.
In my opinion, LDS is evolving along with User Interface API and developers should push for prototyping before accepting solution & stories on projects.

A brief on Lightning App Builder (LAB)
Lightning Experience is usually build from experience lightning components, but in a single view you are looking at multiple components on a lightning page and Org can have multiple applications which are accessed & switched using the navigation menu. Lightning Components as such is not accessible in production orgs by itself.
Lightning App Builder is point & click tool, that helps create custom pages for Lightning Apps, Lightning Experience & Salesforce Mobile Apps.
App Builder helps admins customize App branding & settings, drag & drop lightning components on canvas to configure page layouts for different page types like Home Page, App Page & Record Pages. It allows you to configure components to implement dynamic by allowing admins to create component visibility filters with ease while having coffee discussions with the app users.

Links & Reference
a) https://trailhead.salesforce.com/modules/javascript-essentials-salesforce-developers
b) https://trailhead.salesforce.com/modules/lex_dev_lc_basics
c) https://trailhead.salesforce.com/modules/lightning_design_system
d) https://trailhead.salesforce.com/modules/lightning_data_service
e) https://trailhead.salesforce.com/modules/lightning_app_builder

Wednesday, September 12, 2018

JTD-DesignerSeries-6-VisualforceBeginner


What is Visualforce
Who doesn't know about MVC, a pattern which almost all 3-tier web architectures & framework consider as foundation for developer tools & technologies[M-Model, V-View, C-Controller]. User Interface is another term to define the view layer, and primarily rendered by browsers these days.
Visualforce framework helped developers quickly create pages with standard styling by re-using tag based markup components & common actions with standard controllers. Developers write custom controllers & extensions to override the standard behavior, and permissions are handled with profile as custom controllers execute in system mode.
Visualforce Rendering
Visualforce is compiled, stored in the lightning platform and rendered as html by browsers. When the page is saved by a developers, it is complied and error free metadata is saved to the org repository on the cloud. When the page is requested, visualforce renderer transforms the metadata instructions into the html DOM and rendering by the browser updates the view layer.

Visualforce Page runtime is quite different in classic & lightning, with classic container owning the execution context & provides lot of control to the developer but lightning experience creates an iFrame context within the lightning container and it requires quite a bit of tweaking when the visualforce component has to use lightning platform services, though sforce.one utility is embedded in the component.
Visualforce Mobile
Salesforce Classic, developed primarily with Visualforce & Apex, became mobile with launch of Salesforce1 mobile app. Architects, usually say, that it is quite important to understand how we are going to address the mobile requirements in an enterprise ecosystem rather than in Salesforce ecosystem. Not being a savvy mobile consultant, I would say, generically, understand the Level 0 / Level 1 process & data points, [Are we talking about native mobile app / or Salesforce App, Data layer is with 2-3 salesforce objects / or are we talking custom data model in salesforce / or outside CRM application], and discussion on these data points can help with the design layer. Remote Objects along with SLDS can be used to create standard visualforce mobile components with standard objects, and developer can use advance javascript skills to use Javascript Remoting.
Visualforce Mobile provides easy low code tools like global actions, object specific actions & mobile cards to improve the mobile experience in Salesforce App. 
Visualforce in Lightning Experience
By now we understand that Lightning Experience is primarily powered by lightning components similar to other Javascript frameworks, but Salesforce suggests that for the most part standard visualforce components should work in Lightning Experience, and developers should able to apply styles to provide the Lightning look & feel. Though, Org with lot of visualforce customization should use the Gap Analysis & other methodologies for a successful upgrade & rollout.
Links & References
a) Visualforce Developer Guide
b) https://trailhead.salesforce.com/modules/visualforce_fundamentals
c) https://trailhead.salesforce.com/en/trails/lex_dev_lc_vf

Thursday, September 6, 2018

JTD-DesignerSeries-5-LightningExperience


What are upgrades, greenfield ?
In enterprise ecosystem, I have worked on quite a few upgrade projects, some small where we are retrofitting the code to support versioning, patches with 3-6 month timeframe, ; some medium where some of the major components of an application are re-written along with framework upgrades with 6-18 months timeframe; and then there are transformations initiatives that runs from top to bottom for several years in phases, re-define business processes & impact several applications.
I think Lightning Experience upgrades can fit in any of these buckets and for enterprises not having classic environments can go with greenfield, though existing classic implementation can start with partial greenfield for a business unit to taste lightning without impacting classic users.

Lightning Experience
It is quite huge and umbrella term for lot of features & services, through simply it's a salesforce way improving productivity for different personas, making application more aesthetic & beautiful, better positioning for its platform & services with trends like mobile, social.
a) As a user, Lightning experience is a different feel where features & services are easily accessible with efficient navigation, handy notes & recent items, cool layouts, list view & dashboards. Coarse grained features like Home Pages, Opportunity Workspace, Accounts & Contacts etc have been configured with new underlying components like Assistant, news supported with customizable view layer of List Views, Kanban Views. Users can even configure apps with custom branding & styling, communicate faster with better integration with gmail, outlook etc.
b) Lightning Experience not just focuses on improving the experience for all personas in Salesforce ecosystem, there is significant investment in lightning adoption tools like Lightning Experience Readiness Check, Optimizer, Switcher, shared & configurable components like Path, Timeline, Notes etc.
c) Lightning Experience, though really transformational with a forward looking vision, keeps the core of the application still intact by reusing existing Object Management Layer, supporting & improving platform technologies like Visualforce, Apex and helping architect & developers innovate with app centric & component based architectures.

Lightning Experience Features
I. Setup & Navigation
a) Setup has improved quite a bit in Lightning Experience with simple navigable structure, broad categories [Administration, Platform Tools, Settings], better tree nodes, quick find, alphabetic ordering.
b) App Launcher & Navigation Bar not only helps with consistent & simple UX across several apps, but also allow apps to have contain specific object tabs, dashboards & custom color & logos.
c) Better search capabilities with global search box on each page, object specific searches & refining the search results with filters.
d) Object Manager is one place where you can manage all your standard & custom objects, their related functions [Fields & Relationships, Page Layouts, Record Types, Validation Rules, Buttons & Links....]
e) Service Setup flows offers a guided step-by-step experience to walk you through setting up email support, integrating with Twitter and Facebook, enabling a knowledge base, and creating an online community.
II. Lightning Sales Tools
a) Sales Apps are enhanced with action based workspace [Opportunity Workspace] with customizable Path & Activity Timeline components.
b) Opportunity Kanban view organize sales rep deals by Stage in the pipeline and sales reps can easily toggle between list grid view & kanban view.
c) Leads Workspace eases qualifying & converting leads for Sales Reps.
d) Accounts & Contacts have been optimized with components like Highlight Panel, News & Twitter Integration, Hierarchy Views, contact to multiple accounts settings.
III. Lightning Customizations
a) Lightning Apps can be configured with most standard objects, custom objects, Visualforce tabs, lightning components & lightning pages tabs.
b) Lightning App Builder can customize Home Pages, configure lightning components visibility to create dynamic lightning pages.
c) Lightning Experience also supports customization of List Views, Record Pages, Compact Layouts, Buttons & Actions.


Lightning Experience Rollout
Rollout Approach provided by Salesforce follows three steps:
I. Discover
[Are Stakeholder onboard, Do we know the impact on existing functions, Have we done the gap analysis, What features can we get right away, Are we ready]
II.Roll Out
[How we are phasing the rollout, What is the feedback from pilot users, What we should test & How to measure success, Create Mitigation Plans, Communication & Training, Go-Live]
III. Optimize
[Gather Feedback from Business Users, Monitor Metrics, Weekly Executive Reports & Summary, Execute Mitigation & Stabilization Projects, Celebrate on Successful Rollouts]

Links & References
a) https://trailhead.salesforce.com/modules/lex_migration_introduction
b) https://trailhead.salesforce.com/en/modules/lex_customization
c) https://trailhead.salesforce.com/modules/lex_migration_whatsnew
d) https://trailhead.salesforce.com/en/modules/lex_migration_rollout

Tuesday, September 4, 2018

JTD-DesignerSeries-4-ApexBeginner


What is Apex
Salesforce Classic CRM Apps are architected using MVC frameworks, and delivered in a cloud computing based SAAS model as oppose to on-premise apps. Java, based on Object Oriented Principles & being platform neutral, open-source, was hugely supported by Java EE & Spring community, from 90s to 2000s & even today. Though Force.com platform multitenant design requires a language that is hosted & complied on the platform, support efficient utilization of resources by sticking to governor limits & integrated with Data layer through sObjects to support ease of use. Then, Salesforce engineering team designed Apex Code as first multitenant, on-demand programming language for developers interested in building next generation business applications. So, Apex is strongly typed object oriented language & follows Java like syntax and integrates with other features & services provided by the platform to build next generation lightning cloud applications.

Apex Execution Engine
Apex is compiled, stored & run entirely on the lightning platform. Apex code is compiled and stored as metadata that is interpreted by Apex Runtime Interpreter. Categorically, the runtime behavior of Apex Execution resonates more with scripting languages like Javascript, Ruby and quite different from Java where compiler generates the .class files.
Developers uses tools like Developer Console, Force.com IDE to write, debug and test the apex code.

Apex Language Support
Apex language support is quite similar to other object oriented languages by providing data types, collections [List, Set, Map], Control Flows [While, For Loops] & supports Abstraction, Encapsulation by providing Classes, Objects & Interfaces.

Unlike Java EE / or Spring framework which uses loosely coupled modules & ORM tooling to manage the database objects, Lightning Platform is tightly integrated with its data layer through sObjects. Apex developers create sObject variable for custom & standard objects, and collection like List, Map are used heavily to implement programming constructs in the form of Apex classes & methods.

DML statements [insert, update, delete] & SOQL queries helps query & manipulate object records and bulk queries are used to avoid hitting governor limits on the multitenant platform.
Invoking Apex
Salesforce ecosystem supports multiple delivery personas, from BA [no code], Admin [low code], Developers [code]. Solution that addresses requirements with code push developers to write Apex code, but implementation can span across multiple layers and apex component can be part of it. Few ways to invoke apex component:

a) Apex Triggers enable programmatic control before & after changes to Salesforce records like insertions, updates, deletions.

b) Asynchronous Apex enable capture the event data & behavior, spawn another thread for long running methods & jobs and provide an acknowledgement to calling thread.

c) Apex supports inbound and outbound integration scenarios with Apex Integration services. Apex runtime framework provide WSDL2Apex utility & Httprequest classes to make outbound callouts. Apex classes can be exposed as SOAP Services (webservice) and Restful resources (@RestResource) to support inbound callout from external applications.

d) Custom UI behavior can be implemented with Visualforce Pages integrated with controller layer using custom controller & extensions written as apex classes.
Testing Apex
Salesforce Deployments require 70% code coverage when the release artifacts have apex components. These days, best practices like DRY, Test Driven Development are necessary to support frequent releases & agile approaches. It is quite important to test bulk actions to ensure that runaway apex code don't monopolize resources.

Testing framework supports unit test with classes annotated with @isTest & test setup methods with @testSetup.
Links & References
a) Apex Developer Guide
b) https://trailhead.salesforce.com/en/modules/apex_database
c) https://trailhead.salesforce.com/en/modules/apex_testing
d) https://trailhead.salesforce.com/en/modules/apex_integration_services
e) https://trailhead.salesforce.com/en/modules/apex_triggers

JTD-DesignerSeries-3-AdminBeginner


How Salesforce Architecture is different
Salesforce applications reside in the cloud, which means few things:
a) Application & Platform services are accessible through the browser and there is no need for on-premise installation.
b) Platform generates freebies like Page Layouts, mobile access with the help of metadata layer and provides API first approach to provide ease of customization.
c) Multitenancy supports sharing of underlying infrastructure which helps Salesforce deliver services to all of its customers in the same way at a lower cost.
d) AppExchange allows customers to take extensibility of salesforce app & platform to next level by allowing partners develop out of the box apps & resources for enterprises, similar to Apple App Store & Google Play Store.


Objects & Relationships
a) Data Model are defined in the form of custom objects, Lookup & Master-Detail relationships using Platform tools like Object Manager.
b) Data Management utilities like Data Loader helps import & export data sets from local files into objects into Salesforce Cloud environments.
c) Developers uses SOQL & DML programming constructs in Apex Classes to manipulate the application data layer.


Customizations
a) Custom tabs on objects & components can be stacked to create Lightning Apps to support coarse grained business functions. Tabs can provide a layer of abstraction to the underlying objects as a reusable component which can be used in different applications.
b) Lightning Apps can be powered by other platform services like chatter, reports and further allow admins to configure the app behavior & styling by costunizing list views, page layouts, compact layouts, quick actions, custom buttons etc.
c) Salesforce Mobile App is readily available with the platform at no additional cost and uses the power of metadata & APIs to further customize the app behavior. Mobile App can then be customized with Quick Actions (Global & Object Specific), Compact Layouts & Navigation (SmartSearchItems).
d) Platform allows reporting & tracking as object configuration and allow admins to configure different report view based on report type, filters. Dashboards allows admins to add different components (Reports, Visualforce, Lightning) as visuals on a single dashboard page to show key metrics & trends.


Security
Salesforce security model defines controls at different level starting from org, object, field & individual records.
a) Access to org is controlled by managing users, setting password & IP policies, enabling single sign on & authorization access using protocols like SAML, OAuth.
b) CRUD access on objects is controlled using profiles & permission sets. Users are assigned a single profile and can be assigned multiple permission sets to provide additional access.
c) Requirements like managing access to sensitive fields like SSN can be managed by restricting field level access using field level profile settings and additional access can be granted using permission sets.
d) Object Data, in the form of records, has a record owner, and record level access is controlled in four ways. Generally model suggests to lock down the data to most restrictive level with Org-Wide Defaults and then use tools like Role Hierarchies, Sharing Rules, Manual Sharing & Apex based sharing to open up access for profiles, groups, roles, users.



Links & References
a) https://trailhead.salesforce.com/trails/force_com_admin_beginner
b) https://trailhead.salesforce.com/en/modules/data_security

Sunday, September 2, 2018

JTD-DesignerSeries-2-DeliveryOutline



Delivery with Platform Skills
Along developing learning patterns from developer modules, we also need to build on the playgrounds. Some of the starter apps like Suggestion Box, Conference Management, Battle Station can help understand the agility of the platform.

On-Boarding Developer Resources
Typically, a developer is on boarded and will have to go through the product overview, as-is architecture & process understanding, and deep-dive into the requirements / user stories. Usually enterprise application developers spend quite a bit of their time in understanding the existing data model and design object model on salesforce platform to enable automation of business functions & processes.


Data Model Design
As developers participates in team discussions, they use platform tools like Schema Builder, Object Manager to work with custom objects & relationships.
a) Recruiting App defines the data model by creating six custom objects [Position, Candidate, Job Application, Review, Job Posting, Employment Website].
b) FriendsWithBoat App defines the data model by creating three custom objects [Boat, BoatType, BoatReview] and using standard objects like contact, user.

With Salesforce design being metadata aware, lot of freebies comes with the platform like Page Layouts, mobile and there are point & click tools like App Builder, Tabs which really eases the app configurations.


Comprehend Delivery
Product teams go through the ideation phase / or business scenarios sessions and the feedback from those discussions is transformed into the features by product owners. Architects, as platform owners leads design discussions with the team of developers to perform technical analysis on the business scenarios.

In this process, business scenario is mapped across architecture / system layers like UI, Services, Data and tasks are created by Leads / Scrum Masters with the focus on definition of Done.

At times, different solutions are evaluated, proof-of-concepts are done to develop an implementation plan, and deployment & releases schedules are published to attain the desired outcome.

Platform tools like APIs, Change Sets, Scratch Orgs, Lightning Components helps developers build & deploy artifacts based on delivery enablement methodologies like DevOps and Agile.

In an enterprise environment, you will find that Salesforce application, processes & connects with other enterprise systems & resources to deliver a streamline user experience. It is quite important to formalize standardization by documenting release processes, identifying common tools for Version Management, Continuous Integration, establishing peer review & testing guidelines.

a) Use Git as a source control repository, formalize a branching strategy for team development, configure builds & automated tests using tools like Jenkins / TravisCI and snapshot releases with Maven & Artifactory / Nexus.
b) Work with Sandboxes & Scratch Orgs to develop & test feature & user stories before pushing it to the testing environments, and create a feedback loop to manage quality control.
c) Leverage new toolset like Salesforce DX along with ChangeSet, Ant Migration Utilities to manage artifacts efficiently with CLI.

Links & References
a) https://trailhead.salesforce.com/en/modules/alm_deployment