There are more unnamed scripts than named ones. You may
start to think it’s an allegory for your life. Maybe you should bring that up
with your therapist next time. That’s always the problem with any system that
grows up organically over time. If you’re not careful, you will end up with
something that is impossible to maintain. Tomorrow, you come into work and a
script breaks in one of your 300+ accounts. You have no idea how to find
it. Logging in and out of accounts can eat up hours of your time in a week. But
you can stop (or at least slow) the process with a little bit of vigilance
and planning. Today, I’ll walk through three techniques you can use to help
lower the long-term maintenance of scripts in your accounts.
Gather Your Existing Scripts MCC Accounts
If you were developing
scripts before the advent of MCC scripts, you probably have the same script
copied into multiple accounts. Of course, that means you also have the same bug
copied into multiple accounts as well. Bringing scripts like this into the
MCC level means that there is a single piece of code to look at when
debugging an issue.
Here is some generic code
you can use at the MCC level to start running your scripts across multiple
accounts using labels.
His code will run through
all your accounts and search for the ones labeled with the name used in
the SCRIPT_LABEL variable. When you schedule this script to run daily, it will
process all accounts with that label up to MAX_ACCOUNTS, which is the maximum
number of accounts you can run the executeInParallel() function on.
Create A Test MCC Away From Your Main MCC
I think the best way to keep
your production accounts safe from script bugs is to open a brand new MCC
account and create test accounts underneath it.
Since most of my stuff is
pretty experimental, most of my accounts are test accounts. This set of test
accounts and the MCC is where you will do all of your experimenting and testing
for new scripts.
Create A Code Review Process
The idea is similar to having someone else proofread your
writing. Since they are unfamiliar with the writing and topic, they will be
objective and find issues or code bugs that you may have missed.
I recommend
that before you move any code from your test accounts into your main MCC, you
find someone in your company to sit with and walk through how your code
works and what the code looks like.