How to have a great Development Environment

How to have a great Development Environment

I recently started a new project from scratch with 3 colleagues from OutSystems. We installed a new development environment, a brand new database engine and started to implement stuff (you know the drill…). Everything worked out well, and in a single day we installed the platform and started to deliver.

Two months passed by and as we looked back, we noticed that our development environment was not that fast anymore. It wasn’t like everything was now taking twice the time, but it was like a few more seconds in every publication. Reminded me of the feeling when I get that extra Sundae Ice Cream… a few grams more makes me fat…

New Year at the door and the frustration was setting in... “what can we do to improve this” was an everyday topic.  We don’t have a dedicated SysAdmin to deal with our development Environment, so, as a New Year resolution we decided to tackle the problem ourselves.

Here’s how we dealt with the problem:

1.       Follow the installation checklist carefully
We looked back to our installation and checked it against the checklist. We took special care in our ApplicationPool configuration. This will keep your worker process safe from recycling and you from stalled publications. We also revieweded the remaining recommendations, like Page File configuration and Data Execution Prevention settings for optimum performance.

2.       Keep your database clean
We hadn’t noticed, but with all our publications, the database was growing quite fast with all the stored eSpace versions that we were not using anymore. Luckily the platform has a feature to prune old eSpace versions. Go to ServiceCenter > Factory > eSpaces > Check Old eSpace Versions to Delete.

We also created maintenance scripts to update indexes statistics and rebuild indexes overnight, following this tips from OutSystems Support Team .

3.       Clean up ASP.NET files frequently
The temporary folder with the ASP.NET compilation files was also getting quite large. We’ve followed this post on how to keep it in shape.

4.       Tune your anti-virus suite
The anti-virus suites usually include network traffic scanners and a I/O on-access scanner, causing resources overhead that could hinder the compilation performance. We looked at our server and excluded some folders form this on-access scanner. This can improve I/O performance and reduce kernel CPU usage significantly. Information on the key directories to exclude can be found here.

5.       Check the network
Since we do a lot of publications, and our eSpaces were getting a bit large, we wanted to make sure that we have a fast network. At the end of the day, the sum of all eSpace uploads can be significant. We didn’t make any change, but it’s a subject that you don’t want to overlook.

6.       Check You Application Architecture
If you didn’t attend to the NexStep presentation “The Art of Designing OutSystems Architectures”, you might not be aware of this, but keeping a good architecture is key to a factory healthy grow. The added bonus: it also aids in the performance of your publications. The less code the compiler has to work on, the faster it will be.

7.       Invest in hardware
And last, but unavoidable, need for hardware was also revisited. Keep an eye on your CPU consumption, memory and disk I/O. There’s a nice post on the network about the usage of RAM Disks. Nowadays SSD are probably a great boost if you’re aiming for an I/O Boost.
So yes, we spent some time, spent some money (you now who engineers love to buy new hardware) and at the end of day, we get the million dollar question from our top management: “How much did you save anyway?”
Little help if (and you will) run into this question, here’s the (conservative) math:
            5 seconds in every publish
      X 15 publishes an hour by developer,
      X    8 developers working
      X    8 hours a day
      = 11 hours a month

 Now that’s saving! Go spend it on Sundaes!

What about you, how do you keep your environments in good shape?
Nice tips, Pedro.