What I can remember from the exam

After successfully completing the development lifecycle and deployment designer exam a few days ago, I’ve attempted to write up what I can remember of the most important items to study. Of course, the most sensible thing you can do is to work through the Trailmix provided by Salesforce in order to prepare, but hopefully, this will give you some additional insight on what to expect.

There were a few curveballs in this exam and there is no substitute for solid experience in this particular case. Developers will be very familiar with the topics of continuous integration, the metadata API, command-line deployment tools and version control. So if you’re not a developer, chances are you may have to study the content very hard and/or take the opportunity to be involved in a complex project with a formal release process before you take this certification exam. I’d recommend you watch the videos and webinars offered by the resource guide at the very least.

Sandboxes

Knowing the types of sandbox available, their limits and which ones to use for each part of the development process is key:

Full copy sandbox

• A full copy of your production environment – data and metadata.
• Used for UAT, training and as a pre-production (“staging”) environment. The place for dress rehearsals.
• Can be refreshed every 29 days

Partial copy sandbox

• all your metadata is copied from Production
• sandbox templates can be established to copy a set number of records per object down from Production
• 5GB storage for data
• 5GB storage for files
• can be refreshed every 5 days

Developer Pro

• all your metadata is copied from Production
• there is a little more storage than a developer sandbox
  • 1GB for data
  • 1GB for files
• can be refreshed every day

Developer

• all your metadata is copied from Production
• 200MB storage for data
• 200MB storage for files
• can be refreshed every day

In the first instance, even if it’s just a report you want to build quickly for someone….if you have any other workstreams taking place, those developers need to have the latest version of Salesforce they can get – including your new report or picklist values.

External objects

Having been through the resource guide provided by Salesforce, my first question was a bit of a curveball. My advice? Get to know the ins and outs of external objects and Salesforce Connect.

Something that is also important is the ability to confirm whether external objects are available to deploy as custom objects or as external objects in their own right. I was confused by the resources which specified that the API names of external objects are suffixed with __x instead of __c, but when examining the options available to deploy via change set, there was no provision for external objects and I am sure I remember seeing them available to add to a change set from the custom objects menu. Your comments on this are most welcome.

Code Repositories and Automated Builds

Be able to identify the capabilities and limitations between tools such as

• Force.com IDE
• Force.com Migration Tool (formerly ANT)
• Git – where would you push/pull from, given a scenario
• Jenkins – incorporating automated test results

Continuous Integration

To say I was grateful for having spent 4 months at NOWTV in 2013 are a bit of an understatement. The company uses continuous integration, repositories and build tools as standard practice; I’d’ve struggled with this if I’d not had that experience.

Topics that spring to mind:

• How it works
• Best practices around branching techniques within a build tool (e.g. Jenkins, Bamboo)
• Maximum size of zip files

Release Management

You’ll need to know what constitutes the following release types and best practices for deployment:

• Daily release
  • Changes such as reports, picklist values, list views
  • Usually, these are made straight in Production
• Minor release
  • A new feature that requires testing and formal deployment from a sandbox, e.g. a dashboard
• Major release
  • Larger and more complex projects – e.g. a bringing a new department into Salesforce or building a new feature, e.g. a community

Think about the release processes you would use in order to deploy something quickly, taking sandboxes into account. What matters most is matching the requirement to the best process and sandbox combination.

Testing

Absolutely fundamental to consider the following:

• Which tests are most appropriate for a given scenario (unit testing, load testing, stress testing etc.)
• Think about scalability. How high would you go for load testing if a company plans to grow?
• The fastest way to give testers some test data to work with, in the UAT environment

Waterfall vs Agile

The key here is that there is no right methodology. The methodology has to suit the environment the customer is in. Expect to be tested on the most appropriate methodologies for certain projects.

• For longer-term projects with approval gates, multiple departments involved and careful documentation, just remember you would want to use Waterfall
• For changing requirements and business needs, Agile is more appropriate.

Governance

• Yay, design standards!
  • How could design standards be enforced to prevent admins from getting confused about what has been built?
  • Design standards could be offered as possible solutions for other scenarios

• Old implementations (most pertinent in this day and age!):
  • What typical challenges would be faced in that situation, e.g. multiple triggers on the same objects, stuff that was coded and could now be declarative…etc

• Think about the decisions you would make as an architect, given the scenarios of someone being short of time and the need to get something deployed quickly, despite other work going on:
  • How would you deploy something quickly, like a dashboard, list view or report:
    • Yes, this is a typical Business-As-Usual example, but if a developer was working on something for a future release, they’d want to be certain they’re not reinventing the wheel and that the new requirement will not affect the proposed data model for that future release
  • How would you deploy a new field, knowing it may have an effect on some code, flows, or an existing inbound integration
  • Hotfixes alongside a long-term project – know how you’d deal with those

I stuck with the principle that there should be a Production change freeze whenever you have multiple workstreams, with all work (even BAU and hotfixes) being put through a sandbox first, tested, accessible to developers for regression testing, before being deployed separately, otherwise users would have to wait too long for the fix.

More here:

So, at the end of the exam, with 20 minutes left to check my work before submitting, I really wasn’t sure if I’d passed. I got about halfway through checking, with 2 mins to go and thought I was happy with most of the questions, so I submitted it, and…..got one step closer to System Architect. Yes!!

I hope you’ve found this article helpful – please tweet me @gemziebeth if you’d like to share any other insights and, ladies, please come and find our group, Ladies Be Architects on the partner community to share your thoughts!