This is a follow on article from Supporting a Classic ASP application

So in the intervening 15 years since I last touched Classic ASP, my knowledge and understanding of good coding practices went through the roof, thanks to working at Timble. Like a Michelin Kitchen I was exposed to the very best practise there was on offer. 

I was keen to see how much of this new ways of thinking, could be applied to this failing project. 

Version control

Previously the site had no version control. Files were edited on live; using notepad and the changes made, affected 15+ sub sites. The chance of disaster was severe.

The very first thing I did; even before the sites were officially mine, was to install git and run:  

```git init && git add . && git commit -m "#main benchmark the code base```. 

Moving secrets out of the repository

Timble was religious, any secret, api or otherwise incorrectly committed to the repository, the keys were removed and reset. The danger is, if a private repository is mistakenly made public, script kiddies can use the powerful search features of Git or Github to trawl for these secrets and you've been pwned.

In linux this is possible thanks to environment variables, which can then be read by the application. I was pleasantly surprised to find that Window's also has the notion of System Environments, and what's more, can be programmed by PowerShell. Winner.

Automatic site creation

The next time we needed a new site, we simply issued the `create-new-site`; which creates the Github repository, introduces the code base, integrates the site into the local development server, and we are off and running. No more finger problems.

Although thankfully work is fully underway to replace all the Classic ASP sites, with a more modern platform. 

Documentation and testing notes

We use Git in conjunction with Github because their powerful API allows us to spin up new development sites, repositories, document issues, create READMEs and wiki pages, allows us to manage tickets through Kanban boards, and get essential comments and suggestions from Stakeholders. Testing notes and documentation why we had taken steps, became essential from this point forward. 

The code base I inherited, had absolutely zero hand over notes, no explanation why code was changed, when it was changed, or the impact the change had on the application. I was keen to avoid this for the future. 

Database migrations

We all know that some code changes require the database to be updated. Whilst full automation, the kind we had employed at Timble was off the cards, we could track migrations in individual text files; with a name that reflected the feature/ Hotfix branch that provided the up and down methods, this has proved to be equally valuable.

Offsite database backups

In the event of disaster, we take twice daily backups of every sub site. This is managed through a Window's Scheduled Task, that sets off a bash script, that interfaces with mysql and then uses an AWS SDK to upload these files to an S3 bucket.

Healthchecks and log monitoring

Cloudflare is used to ping our sub sites each hour and check for a correct status code, in the event of a site falling down Slack is then pinged. A third party log collation service gives us visibility over the server logs for the first time (without having to resort to notepad). It's not quite Grafana and Prometheus, but it's a big step forward. 

Web Application Firewall

Again Cloudflare provides our Web Application Firewall (WAF), if you have ever studied your server logs, you will notice that as soon as an IP address starts to resolve, your sever will be bombarded with fishing requests for environment files, common WordPress files, directory traversal and many more suspect requests. 

a WAF helpfully prevents 95% of these requests.

Local, staging, production

Far too many sites have been broken by me, before I adopted this philosophy. Code is developed locally, shipped to staging for a test; once we have sign off, is the code shipped to production. One of many great things I've learnt from https://www.12factor.net/ 

The only dodge; due to prohibitively high server costs, staging and production are one and the same. Which therefore leaves open the problem of a bad code patch to staging also taking down production... Trust me this has happened to me in the past. 

More details about the local environment can be found in Supporting a Classic ASP application.

Managed deployments

Like database migrations full seamless deployments are not going to be possible; but rather than copying and pasting files into place, we have git version control. So when a Pull Request is merged to main, we can hop onto a terminal and `git pull --rebase` to pull down the latest changes.

 Depending on any associated database migration we can either run these before or after. In the event of a problem, down migrations can be run, and we can roll back to an earlier git commit that worked.

Modern front end development

Classic ASP might be dead; but that doesn't stop us bringing over front end node developments, such as Webpack, SASS, compiling, minification, linting, browser sync and watch.

The company has a great Designer who comes up with some really good looking web pages. Might as well use the best the modern internet can offer to match these designs. 

Sendgrid for site emails

When the in-house email system started to fall over, we had to find a replacement. Sendgrid was an obvious choice, however the nested array of data that it requires to send an email was a problem. Classic ASP only has very rudimentary array support (don't even ask about objects), so we had to result to JSON to build up these arrays.

Now we have visibility over how these emails are tracked, we can tell if they are delivered, opened, clicked, bounce or marked as spam. The second generation sites based in PHP go one step further and use Webhooks to create a rudimentary CRM system for emails.

Different ways of working and collaborating online

The designer used to pull his hair out trying to get feedback from stakeholders and keeping track of tickets. Slack and Kanban boards have helped the organisation get more effective in communication and providing feedback quicker. 

Using virtual chat, to increase our levels of customer service to the end users was another important development.