3 ms·

Now you create an interesting set of issues for the quality and security tests. How do you test code quality and code security as part of your pipeline for all

by geggam 7y ago

Now you create an interesting set of issues for the quality and security tests. How do you test code quality and code security as part of your pipeline for all of those different versions on the fly ? eg some run python 2.7 and some run python 3.0

heretoo 7y ago
Let me break your points down (using python 2.7/3.0 as the example): a. Code quality - tackled at code review time, and probably not dependent on python 2.7/3.0 differences; if they are version dependent then again it's a code review process. b. Code security - again, code review Additional: c. Third party dependency vulnerabilities: detection should be automated; github now supports automatic checks that open pull requests for vulnerable artifacts. d. user acceptance tests - seems unlikely that two versions of python are used for the same part of the system. Docker (especially docker-compose) makes it more visible as to what will be deployed. In fact, it may actually be better for security when those security checks of a system can be made before it goes to production, because the whole stack can be built, audited and executed locally.
- geggam 7y ago
  So you dont use automation like sonarcube / qualys and other tools ? Our corp requires this at a minimum to even be deployed to development. Let alone staging / prod
lostapathy 7y ago
Your concerns are real, but they are a separate problem. Regardless of the downstream testing/integration concerns, I work with projects with multiple environments, ranging from current Rails apps to a Rails 2 application (that lives in a VERY isolated environment as an internal-app for a cheap "customer"), with various things in between. I also contribute to some open source projects that want weird environments. I've got those projects on my plate regardless of your downstream concerns (which are very valid). However, Docker lets me work on each of them in isolation from one another, and also in a way where none of the goofiness is leaking out into my dev workstation. Prior to spinning it up in Docker, the Rails 2 app I mentioned could only be worked on in production because setting up a dev environment for it that didn't require removing all the modern stuff was effectively impossible. So while I'm embarrassed to still support that project, at least I have a way to do so and a transition path forward.

by geggam 7y ago

heretoo 7y ago

Let me break your points down (using python 2.7/3.0 as the example): a. Code quality - tackled at code review time, and probably not dependent on python 2.7/3.0 differences; if they are version dependent then again it's a code review process. b. Code security - again, code review Additional: c. Third party dependency vulnerabilities: detection should be automated; github now supports automatic checks that open pull requests for vulnerable artifacts. d. user acceptance tests - seems unlikely that two versions of python are used for the same part of the system. Docker (especially docker-compose) makes it more visible as to what will be deployed. In fact, it may actually be better for security when those security checks of a system can be made before it goes to production, because the whole stack can be built, audited and executed locally.

geggam 7y ago
So you dont use automation like sonarcube / qualys and other tools ? Our corp requires this at a minimum to even be deployed to development. Let alone staging / prod

lostapathy 7y ago

Your concerns are real, but they are a separate problem. Regardless of the downstream testing/integration concerns, I work with projects with multiple environments, ranging from current Rails apps to a Rails 2 application (that lives in a VERY isolated environment as an internal-app for a cheap "customer"), with various things in between. I also contribute to some open source projects that want weird environments. I've got those projects on my plate regardless of your downstream concerns (which are very valid). However, Docker lets me work on each of them in isolation from one another, and also in a way where none of the goofiness is leaking out into my dev workstation. Prior to spinning it up in Docker, the Rails 2 app I mentioned could only be worked on in production because setting up a dev environment for it that didn't require removing all the modern stuff was effectively impossible. So while I'm embarrassed to still support that project, at least I have a way to do so and a transition path forward.