All developers know that setting up a development environment is no easy task. It can take hours or days, and you have to worry about dependencies, incompatibilities, versions, previous installs, credentials for AWS legacy, SSO, and GitHub, structure, and conflicts between projects.
The University of St. Thomas Enterprise Application and Cloud Development team has created documentation for setting up Linux or Linux-like environments either locally or through a virtual environment on your machine.
A basic development environment consists of:
- Python
- PIP
- Git
- NVM
- Node
- GitHub CLI
- AWS CLI
- AWS SAM
- Vim
While power users may enjoy setting up an environment from scratch on their new university-issued computer, casual or newer developers (and power users alike) will enjoy the benefits of using a virtual environment. WSL and UTM, the virtual applications we have picked, work seamlessly on your local machine. Plus, virtual environments provide consistency, separation, and robustness.
There are two overall phases to setting up an environment:
- Installation and organization
- Configure accounts
Phase 1: Start By Picking Your Environment Preference
No matter your OS or preference, the following documentation will get you started and on your way to developing in no time!
Phase 2: Configure AWS, GitHub, and GIT
Once you have installed your environment, check out Configuring your St. Thomas Development Environment for instructions on accessing your AWS and GitHub accounts without credential conflicts!
Go Virtual
Even if you set up a local environment directly on your Mac or Windows machine, you can still utilize the functionality of a virtual environment. (We get it; sometimes, you need the functionality of a local development environment directly on your machine!)
UTM and WSL were chosen because they are lightweight and easy to set up. Internal testing has shown that they don't task resources; they provide seamless integration and a robust environment throughout the day of heads-down development or constant interruptions.
Give a virtual environment a try!
Extend as Needed
VS Code, Git configuration, packages, and directory structure, though recommended, are not intended to exclude the use of other IDEs, configurations, or installations. You and your team may have different requirements. However, any IDE, configuration, and packages outside the scope of the documented base set-up may be outside the scope of knowledge and expertise available from campus teams. It is recommended that developers familiarize themselves with the base environment before expanding their toolset.
Purpose of the Base Development Environment
These base environments, designed for stability and approachability, are intended to accelerate onboarding staff and new student employees and create a standard, stable, replicable, and, therefore, updatable and supportable development experience.
Every machine is different and poses unique challenges, whether a new machine on the lease cycle, an older machine that has undergone several package upgrades and users, or a machine with software and left-over installs that may conflict. Also, failed installs, admin account requirements, and differing install methods can lead to headaches.
WSL and UTM, our chosen virtual environments, play a pivotal role in overcoming obstacles when experimenting with new packages and restoring local development environments. Their low-friction method and suitability for daily development activities make them indispensable.
VS Code has been chosen as the IDE in the set-up process as it is commonly referenced in online documentation and many learning tutorials and is readily available for download from Microsoft and the University of St. Thomas Self Service and Software Center.
The Git configuration recommendations outlined in our documentation are not just suggestions but highly encouraged practices. They ensure the most flexibility and stability when switching between repositories spread across GitHub and AWS CodeCommit accounts.
The included packages represent the most basic installation that would provide a useful environment for the majority of users. Additional packages may be included in the future.
Remote Access is currently unavailable outside of Remote Desktop. However, it is the next logical area to explore as we improve the developer toolset and experience at St. Thomas. The ability to work from anywhere on any machine (without necessitating the installation of an IDE, local, or virtual environment) would provide immediate temporary or ongoing access. This could be achieved using a browser-based IDE connected to a remote environment or a local IDE connected to a remote environment. Security, feature sets, localhost previews, latency, boot, and timeout limitations must be considered.