Software development is a creative process–and it’s a hard process. You need to interpret requirements written by someone else, understand how this impacts your current software design, anticipate how users would use it, and write extremely detailed code to implement how your application should react to the end-user’s needs.
It is not easy to keep all this in mind and on top of that, to follow good software development practices.
What makes this even more complex is that you need a great deal of software. Think of things like the latest IAR (or another vendor) compilers, or maybe the latest header files for NXP hardware, plus your Wind River, QNX, or FreeRTOS operating system, JTAG debuggers, and so on. This is not for the faint of heart, and you also need to stay on top of the latest patches and improvements–it’s almost a full time job.
Any minute spent on updating software is a minute that you could have spent on implementing new features, fixing bugs, or correcting coding standards and coding best practices violations. And any minute spent on maintaining your development environment is a minute wasted for you and your colleagues.
What you really want is to get into your office in the morning, open the codebase that you are currently working on, and be productive right then and there.
VS Code delivers on that challenge! I really enjoy working with VS Code. The workflows are fast and there are so many extensions that make your life easier.
There are two extensions that integrate easily with CodeSonar, and have especially made my life easier: the Remote-SSH extension and the Dev Container extension. Let’s get more into each of those, and why they’re so useful.
Remote-SSH
First of all, there is the Remote-SSH extension. I often work on low-powered laptops or workstations (I really like my Mac Mini), but I have a couple of older high core-count Dell PowerEdge servers in my home lab that I use for larger computing jobs.
With the Remote-SSH extension, I don’t notice the difference. I can edit files in VS Code that seem to be on my local machine, but in reality, the files are on the remote server. This allows me to use the high core count machine for parallel builds, compiling and analyzing projects that contain 100s of thousands of lines of source code, up to low-millions of lines of source code in minutes.
Even better, incremental compiles can deliver results in under a minute.
Now, in my case, I have an on-premises computer, but you can imagine doing this in a cloud-environment as well, with AWS, GCP, Azure, or any other service of your choice.
Dev Container
The second extension that is on top of my list is the Dev Container extension. Containers allow a team to define dependencies in a single place, and then roll them out to many. Even better, they allow one to define dependencies in an infrastructure-as-code fashion and then use them in both local and pipeline builds.
Everybody in the team is using the same environment, in-line with your pipelines!
Let’s take a step back. In many of the deeply embedded environments that my customers live, being able to build, run, test, and debug locally is still an in-grained habit. The hardware that my customers work with is not (always) standard hardware. They are deeply embedded hardware boards with properties such as low latency, low failure rate, low power consumption, specific hardware busses, you name it.
This hardware is indirectly the root of the problem. The hardware often requires specific versions of compilers, operating systems, middleware and such, especially if this is ground-breaking new hardware, like often the case in the automotive industry.
Developers are often required to install software on a weekly basis. Running with old software is a major cause of problems. Keeping your development workstation in-line with what the rest of the team is using is a headache.
Containers are a technology that can remove this headache. And Dev Containers in VS Code provide a way to define the container once in your GitHub/GitLab or other project, and share that within the team.
VS Code allows the DevOps team to create a definition of a project with everything that is needed, thereby offloading the developers. This is typically done by a small DevOps/DevSecOps Team, or a designated person in the development team for truly small organisations.
This allows the developers to clone that project and the immediately get:
- All the source code, of course
-
A buildable environment through Dev Containers
- Compilers
- RTOS
- Middleware
- Debuggers
- Static analysis
- Other tools
- The latest test results, including static analysis results, right in their IDE
The end result? A zero-effort developer on-boarding workflow:
- Open VS Code
- Remote-SSH to compute server
- Clone repo
- Open Dev Container
- Compile, analyze and test (through VS Code Tasks)
This means that in one fell swoop the developer has everything needed to become immediately productive. The productivity gain here is impressive, especially, as mentioned, in environments that require a lot of tools, such as embedded, IOT, automotive, medical, or industrial environments.
In Conclusion
Developer onboarding is one of those best practices in software development that is often overlooked.
People often talk about coding standards, secure coding standards, and code quality standards and yes, these are all important. However, being able to do rapid onboarding should be top of your list too, the time savings are incredible, especially for larger teams.
