Ata Sasmaz

Software Engineer
atIBMin Dublin, Ireland

Benefits of offline development environment

« Home

Summary: Offline development environment is crucial to have development going undisrupted all the time and we can achieve this by easy effort.

When developing modern apps we rely on external services highly, this can be a service as an API that we consume or just a javascript file we are including from a cdn like jQuery from Google CDN.

When we rely on external services like these whenever any of them goes offline or if our internet goes offline we can't develop and lose time. I think this is the worst kind of losing time which can be avoided easily if given some small effort.

I realised if I can minimise the single-point-of-failure dependencies on external services and provide a fail-over for them on development environment in I avoid times where the development environment doesn't get up because in dev environments external services tend to be less stable. Many normal stuff can make an external service inaccessible like IP addresses may change, authentication methods or credentials may change, maintenance can goes on regularly...

In a perfect environment where maintenance never takes down services, where credentials or some interfaces change with a notice period, where IP address change (both client and server) is notified early and internet always stays on external services won't be single point of failure but as we know nothing is perfect when it comes to IT, so better to be on the safe side.

Some things I did to achieve this is on dev environment:

  • Don't use external CDNs, always rely on local files on dev environments
    • Use them on testing (smoke, qa) and production environments only.
  • If there is an API service and when it is inaccessible provide a fail-over with a static data
    • i.e.. let a service return a static data if it is inaccessible and log this as an error but do only in dev environment.
  • Use database versioning, so local, testing and production environments can easily be on the same track
    • We need database versioning even with NoSQL unfortunately.
  • Never deploy these workaround codes into production, keep them separate and keep in dev environment.


Disclaimer: Opinions expressed herein are my personal and do not represent my employer’s view.
This website uses cookies for security purposes and anonymous statistics tracking.