Because we implemented a lot of RouterOS devices, we need keep them updated. So primary we need:

1. Check for new version of RouterOS
2. If new version is availible - send notification
3. If new version is availible - download and install new version
4. If new version is availible - reboot running instance
5. If new version is availible - check firmware version
6. If new version is availible - upgrade firmware
7. If new version is availible - reboot and send notification

Solution, which worked for me:
At the first point, I set up e-mail configuration for sending notification. Because there may be problems with internal mail server, I choose to use gmail. In scripts I also use Identity and current time:

ros code

/tool e-mail 
set address=173.194.70.108 from="Sender Name <anything@gmail.com>" \ 
password="Password" port=587 start-tls=yes user=anything@gmail.com
/system clock
set time-zone-name=Europe/Prague
/system identity
set name=NAME
/system ntp client
set enabled=yes primary-ntp=217.31.205.226 secondary-ntp=195.113.144.201

We must take all process backwards. So we must send notification about successful RouterBoard firmware upgrade:

ros code

/system scheduler
add comment="Send SMS when upgrade was successful" disabled=yes name=\
send-sms-succesful-upgrade on-event=":delay 60s;\r\
\n/tool e-mail send to=\"some@email.eg\" body=\"\" subject\
=\"RouterOS \$[/system identity get name] successfuly upgraded\";\r\
\n/system scheduler disable send-sms-succesful-upgrade;" policy=\
ftp,reboot,read,write,policy,test,winbox,password,sniff,sensitive,api \
start-time=startup

At the next we must make very simple script for firmware upgrade. Another solution isn't possible, because when you're upgrading firmware you will be asked for answer on question about confirmation upgrade.

ros code

/system script
add name=upgrade-bootloader policy=\
ftp,reboot,read,write,policy,test,winbox,password,sniff,sensitive,api \
source="/system routerboard upgrade"

Next we make schedule for firmware upgrade:

ros code

/system scheduler
add comment="Auto upgrade bootloader" disabled=yes name=auto-upgrade-bootloader \
on-event=":delay 100s;\r\
\n/system scheduler disable auto-upgrade-bootloader;\r\
\n/system routerboard\r\
\n:global current [get current-firmware];\r\
\n:global latest [get upgrade-firmware];\r\
\n:if (\$current != \$latest) do={ /tool e-mail send to=\"some@email\
.eg\" body=\"Performing bootloader upgrade from \$current to \$latest\" sub\
ject=\"\$[/system identity get name] \$[/system clock get date] \$[/system c\
lock get time] performing bootlader upgrade\"; /system scheduler enable send\
-sms-succesful-bootloader-upgrade; /system script run upgrade-bootloader; /\
system reboot; }" policy=ftp,reboot,read,write,policy,test,winbox,password,sniff,sensitive,api \
start-time=startup

Next we make schedule for alert about successful RouterOS upgrade:

ros code

/system scheduler
add comment="Send SMS when upgrade was successful" disabled=yes name=\
send-sms-succesful-upgrade on-event=":delay 60s;\r\
\n/tool e-mail send to=\"some@email.eg\" body=\"\" subject\
=\"RouterOS \$[/system identity get name] sucessfuly upgraded\";\r\
\n/system scheduler disable send-sms-succesful-upgrade;" policy=\
ftp,reboot,read,write,policy,test,winbox,password,sniff,sensitive,api \
start-time=startup

Finally we make scheduler task for checking new RouterOS, upgrade and so on. Actually we setup task to run once a week at night Monday/Tuesday at 4:00 AM

ros code

/system scheduler
add comment="Auto upgrade RouterOS Monday/Tuesday 4:00AM" interval=1w name=\
auto-upgrade on-event="/system package update\r\
\ncheck-for-updates\r\
\n:delay 1s;\r\
\n:global current [get current-version];\r\
\n:global latest [get latest-version];\r\
\n:if (\$current != \$latest) do={ /tool e-mail send to=\"some@email\
.eg\" body=\"Performing upgrade from \$current to \$latest\" subject=\"\$[/\
system identity get name] \$[/system clock get date] \$[/system clock get ti\
me] performing upgrade\"; /system scheduler enable send-sms-succesful-upgrad\
e; /system scheduler enable auto-upgrade-bootloader; upgrade; }" policy=\
ftp,reboot,read,write,policy,test,winbox,password,sniff,sensitive,api \
start-date=mar/18/2014 start-time=04:00:00

It is really nice but who would be such kamikaze to automatically upgrade everything without propper testing? Especially when everything works correctly? You can just make your network inoperable, but you can gain nothing. I would not do this.

It is really nice but who would be such kamikaze to automatically upgrade everything without propper testing? Especially when everything works correctly? You can just make your network inoperable, but you can gain nothing. I would not do this.

I fully understand what you meaning. In real I have a specific solution for this. I'm not a brutal device killer . I have setup DNS static record for MikroTik update server and all is going to proxy server, where is setup stable tested version. In network we have currently about 150 devices, so is were important for us to test new versions and if there aren't problems distribute it directly to all devices. Because some devices are between client's buildings on his network and we provide only support and services for him, we can't connect them to central network in Dude and upgrade devices from there. So we're using standard features to do this behind their network.