Software Development Environment

A Software Development Environment is a computing environment that helps a software developer to solve a software programming task.

• Context:
  • It can range from being a Local Development Environment (set up on a single machine) to being a Shared Development Environment (collaborative, server-based).
  • It can range from being an Integrated Development Environment (IDE) with all necessary tools in one application to a Non-Integrated Development Environment that uses separate tools for different tasks.
  • It can range from being a High-Code Software Development Environment requiring extensive manual coding to a Low-Code Software Development Environment or a No-Code Software Development Environment that minimizes the need for direct programming.
  • ...
  • It can include a Source Code Editor for writing and modifying code.
  • It can include a Code Debugger to identify and fix errors within the application.
  • It can include a Compiler or Interpreter (Computing) to translate source code into executable programs.
  • It can include Version Control Systems to manage changes in the codebase and track revisions.
  • It can integrate with a Continuous Integration (CI) system for automating the testing and deployment of code changes.
  • It can be configured to match the Target Environment (e.g., production, staging) to ensure compatibility.
  • It can provide features for automated testing, real-time collaboration, and project management within the development workflow.
  • …
  • It can be based on Software Development Framework's, such as:
    • Visual Studio environment where developers write, debug, and compile code for desktop applications.
    • Eclipse IDE setup used for developing Java-based enterprise applications with integrated plugins for deployment and testing.
    • Jupyter Notebook environment for data science projects, combining live code execution with documentation and visualization tools.
  • ...
• Example(s):
  • VigLink's Software Development Environment, a specific in-house environment tailored for their business needs, and may differ in tooling and workflow from generic environments.
  • OpenGov's Software Development Environment, which is customized for government-related software projects.
  • PlayStation's Software Development Environment, focused on game development with PlayStation-specific debugging and testing tools.
  • Medable's Software Development Environment, designed for healthcare-related software development with a focus on security and compliance.
  • LegalOn's Software Development Environment, which might incorporate tools to handle legal data and privacy concerns in software design.
  • …
• Counter-Example(s):
  • Software Integration Environments (e.g., CI systems), which are typically used for combining and testing integrated code from multiple developers.
  • Testing Environments, where the software is rigorously tested to ensure it functions correctly before deployment.
  • Staging Environments, used to simulate the production environment for final testing before live deployment.
  • Production Environments, where the software is released to end-users and must run in a stable, fully functional state.
• See: Compiler, Interpreter (Computing), Continuous Integration, Revision Control, Sandbox (Software Development).

---

---

References

2020

• (Wikipedia, 2020) ⇒ https://en.wikipedia.org/wiki/Deployment_environment#Development Retrieved:2020-5-1.
  • The development environment (dev) is the environment in which changes to software are developed, most simply an individual developer's workstation. This differs from the ultimate target environment in various ways – the target may not be a desktop computer (it may be a smartphone, embedded system, headless machine in a data center, etc.), and even if otherwise similar, the developer's environment will include development tools like a compiler, integrated development environment, different or additional versions of libraries and support software, etc., which are not present in a user's environment.

    In the context of revision control, particularly with multiple developers, finer distinctions are drawn: a developer has a working copy of source code on their machine, and changes are submitted to the repository, being committed either to the trunk or a branch, depending on development methodology. The environment on an individual workstation, in which changes are worked on and tried out, may be referred to as the local environment or a sandbox. Building the repository's copy of the source code in a clean environment is a separate step, part of integration (integrating disparate changes), and this environment may be called the integration environment or the development environment; in continuous integration this is done frequently, as often as for every revision. The source code level concept of "committing a change to the repository", followed by building the trunk or branch, corresponds to pushing to release from local (individual developer's environment) to integration (clean build); a bad release at this step means a change broke the build, and rolling back the release corresponds to either rolling back all changes from that point onward, or undoing just the breaking change, if possible.

2021

• https://zurigroup.com/blog-best-practices-development-environments/
  • QUOTE: ... 4 Best Practices for Development Environments (shared by a developer)
    1. Establish a local development environment.
    2. Operate a single machine to both run the application and develop on
    3. Adopt source control
    4. Create a safe space for testing within the dev environment

---