How do I get my code up there?

[Chris Pearson]

Disclaimer: The ideas, thoughts, and opinions in this post reflect my own views and do not necessarily represent the views of my employer, Accenture.

Let's talk about the steady state development process. By steady state, I'm referring to the process we use after we have successfully deployed ServiceNow, had a bite of our Go-Live Cake and have high fived our implementation partner.

If you've read some previous posts of mine you'll realize I'm not one to drink the SCRUM flavored kool-aid. So, if you're the type of company whose ServiceNow team is resource challenged or you're not super mature in the software development area, it's ok. You've got this. Let's talk about what can work rather than trying to fill all of the roles needed to run pure SCRUM.

Introduction to The Team:

• Product/Platform Owner
• • The buck stops here. She/He determines platform road-map, helps set priorities and goals for the team, and breaks ties between different customers who are all claiming that their widget is the most import thing to be worked on this cycle.
• Business Analyst
• • The requirement gatherer, story author, and 'Rosetta Stone' between the developers and business process owners
  • In a pinch, a good developer can wear the BA hat if needed
• Developers
• • Developers often wear multiple hats, which could be labeled: Designer, Architect, Tester, Developer and sometimes BA (in SCRUM, these are separate people)
  • It's important to empower your Development team to do two things:
  • • Ask 'Why'. Too often developers are handed a story which instructs them to add a field here, write a business rule there. Don't hand a developer a list of tasks. Instead hand them a business problem to solve and let them determine if you need a field or business rule.
    • Say No. Do not let the tail wag the dog. Just because the business is requesting something does not mean it makes sense to add this capability in the platform. Use your governance process to weed out unnecessary customization.
• The Customer
• • These are our business process owners

How often should you promote code to production?

There is flexibility in this answer. There truly isn't a right or wrong answer, only what works for your company. In my opinion, once a week is too often and once a month is too infrequent. My Goldilocks answer lands on every two weeks...and on Friday evenings (I'll get to why later).

How do we get code out of DEV, moved to TEST/QA, and up to PROD?

Those of us who have been around long enough remember Update Set Merging. Thank goodness we no longer have to rely on that capability. This is 2020! We Batch our update sets now.

Don't be too quick to promote your update sets...batch them all the way up the stack.

Too often I come across DEV teams that are having each individual developer complete their update set and immediately promote that update set into the TEST instance one at a time so their testers can begin their work as soon as possible. This commonly works on other development platforms and this might work for you for a period of time on ServiceNow, but I guarantee that it will eventually come back to bite you. It is too common for multiple developers to be working on different stories but still have an overlap in the ServiceNow objects they're touching/modifying while doing the development work. This will lead to one developer clobbering the work of the other developer. Maybe you'll catch it during testing and maybe you won't. What if a developer promotes their code to TEST and a tester immediately tests it successfully. Then the next day a different developer promotes their code to TEST and clobbers the first developer's work. The tester tests the 2nd requirement and it also looks good. Now we've got a problem. And unless the business catches it during UAT, we're pushing a bug up to PROD.

It is a better development process to define a period of your development cycle for development work only. Say the first X days of your cycle. At the end of those X days, all completed update sets are then batched together and promoted to TEST. This way, the most recent version of two SN objects will be applied rather than whichever one was part of the update set that was applied last. After the DEV period, you switch gears and test all of your work for that cycle. As defects are identified, you make new update sets in DEV and promote as needed up to TEST. Once testing is complete and UAT (customer testing) has also completed, you re-batch your update sets in the TEST environment so that you can promote a single batch to PROD on the date/time of your approved Change Request window.

Why do we push code on Friday evenings?

Clones! Remember those? We should all be performing regular clones from PROD to all of our lower environments. If we are promoting code to PROD every two weeks, we should be performing clones at a frequency of every 8 weeks (or after 4 code promotions). Notice I didn't say every 2 months? We should be staying consistent with our deployment schedule as much as possible. If we have a 2 week cycle, we mean every 2 weeks...not twice a month. When cloning, the copy of the instance is taken from the last good backup of the production instance (which can run at any time of day, but runs at least once every 24 hours). This means that if we promote code on a Friday at 6PM, we should not schedule our clone of PROD->DEV until Saturday at 6PM. Cloning earlier than 24 hours after our last code promotion can lead to the clone NOT including the code we just committed to PROD. This is why it's best to promote code on Friday evenings...so that when it's time to clone, you have the full weekend to manage that cloning process to the multiple lower environments so that when the DEV team comes in on Monday morning, they can hit the ground running to start that next development cycle.