Local Development Environment(s)

What is a Local Development Environment, and Why do I Need One?

#

A local development environment refers to a setup on your personal computer where you can write, test, and debug your code before deploying it to a live server or production environment. This setup typically includes various software tools and configurations that mimic the environment in which your application will run in production.

Components of a Local Development Environment

#

This list is certainly not exhaustive of everything you would need for a LDE, but it does give you an idea of what to think about when building your LDE.

1. Editor: Apps such as VSCode, Sublime Text, Notepad++ is where you write your code
2. Version Control: Git (or others such as SVN) provide version control for tracking changes, collaboration, and recovery.
3. Local Server: Apache, Nginx, Node.js and more provide you with a way of testing and debugging a local copy of your code before it is published.
4. Database: MySQL, MongoDB, provides storage of your content, user information, or any other data set.
5. Build Tools: Used to compile and bundle your code. Tools such as Webpack, Gulp, or Grunt are used here.
6. Containerisation: Docker is used to create consistent development environments across different machines and architecture.

Why do I Need a Local Development Environment?

#

Here’s some of the reasons you may want a LDE:

1. Testing and Debugging: You can test and debug locally before your code is published into a production environment.
2. Faster Development: You can see the results of your changes immediately, speeding up the dev process
3. Version Control: Integrating with Git allows you to manage code versions, collaborate with others, and track all changes effectively.
4. Mimic Production: Configure your LDE to mimic your production environment, allowing you to confidently work on code without impacting the live product.
5. Continuous Integration: Build integration and CI/CD pipelines into your LDE, ensuring that code you write locally can be automatically tested and deployed.

Setting up a local development environment is a fundamental step in software/web/app development, ensuring that you can develop robust, efficient, and bug-free applications, and or services.

A development environment is built to your needs, or the needs of the software/service(s) you are working with. You’ll need to look at what you are doing and install the tools you require.

If you are setting up an environment to work on code for your job, then it’s high likely that your internal documentation covers what you need, a script exists to install everything, or your local IT department can add you to the right application deployment policy to automate the install of everything you need.

My Environment

#

I use multiple environments to achieve my different goals, so we’re only looking at my web development environment, which covers the following…

• Hugo Framework
• React Framework
• Tailwind CSS Framework
• VSCode Editor (+ extensions)
  • Azure Static Web Apps
  • Azure Functions
  • Azure Resources
  • Azure Storage
  • Github Actions
  • Markdown All in One
• Azure CLI Tools
• Git
  • Github, and or
  • Azure DevOps
• Node.js
• NPM
• MongoDB / MySQL / Postgres / JSON / RESTful APIs

I use a lot of extensions in VSCode that I have not listed above. There’s a list at the bottom of this article.

It looks like a lot, but there’s really not much to this setup. It’s enough to enable me to develop web-based apps/services, and the environment only grows by each specific software/service that I add on, such as Hugo, which is what this website is built on.

My Development Process

#

A high-level overview of the development process looks something like this…

1. Write your code / add content
2. Build / compile
3. Test locally (Hugo comes with its own web server)
4. Commit your changes to Git
5. Push your code to your remote Git of choice
6. A Github Action will trigger and take the build output and deploy it
7. Deploy to Static Web Apps for production

The last two steps are automated through Github Actions or Azure DevOps CI/CD Pipelines.

Hugo is a Static Site Generator (SSG) framework for building websites, and at its simplest you can use it just to add content and create a blog, no coding required. The pages, posts and other content is written in Markdown, which is a lightweight markup language for creating formatted text. VSCode has a built-in previewer for Markdown so you can see what it will look like as you type.

When it comes time to build, Hugo will take all of the content, images and other supporting materials and converts them into static HTML ready for deployment to a production service.

In the Github Action you need to specify which branch to deploy from and where your build output is located. Once you have made your changes, or added your content, Hugo needs to be told to build/generate the static HTML, which is placed in the public folder. The Action will then connect to the SWA and deploy the content of that folder to the root of your SWA.

Summary

#

I’d be lost without a solid development environment. It enables me to work on and deliver content & designs in a structured and predictable manner. As I said above, it is a fundamental step for developing your software, and once you build the habits and get used to using a development environment, you’ll never go back.

My VSCode Extensions

#

I use a lot of extensions to make my life easier. You may find some of the useful to you.

1. Adaptive Card Studio
2. .NET
3. Auto Rename Tag
4. Better Comments
5. Code Spell Checker
6. CodeSnap
7. Dev Containers
8. env-cmd-file-syntax
9. ES7 - React/Redux/React-native Snippets
10. Git Graph
11. GitLens
12. Home Assistant Config Helper
13. Hugo Language and Syntax Support
14. Import Cost
15. indent-rainbow
16. npm intellisense
17. Path intellisense
18. Playwright Test for VSCode
19. PowerShell
20. Prettier - Code Formatter
21. Stream Deck for VSCode
22. TabOut
23. Tailwind CSS IntelliSense
24. vscode-icons
25. vscode-pdf
26. vscode-styled-components
27. Word Count
28. Windows Subsystem for Linux
29. YAML