Strider-CD
Feature: Environments
Commit Layer
Update Manual jobs should get commit meta-data.
Deploy only job
Do we let users deploy without testing? In that case, there could be strangeness if they depend on something that would happen in the test phase... maybe we let them be the judge.
"Environments"
Test a commit under multiple environments
Why is this cool?
- test your project under different versions of python, etc.
- deploy to multiple targets
Key Points
Environments are orthogonal to branches
This means that multiple branches (or branch patterns) can point to the same environment configuration.
Branch configuration consists of:
- active
bool - deploy_on_green
bool - environments
list of references
Environment configuration is owned by the Project.
With great power comes great possibility for confusion
We need to be careful that the config page UI makes the base use case (one branch, one environment) obvious and simple. I have some ideas about this.
Backend changes
- jobs will need an
environmentattribute to indicate which environment they came from - most of branch configuration will move into environments, which the branches retaining a reference to the new environment. Auto-conversion will make one environment for each configured branch pattern.
Issues: under the proposed system, in order to deploy to multiple targets you would be required to test your projects multiple times. This redundancy could be eliminated if the complexity of the system were increased to include the idea of a target, having multiple targets for a single environment.
Do we let users deploy without testing?
Yes, I never want to be constrained by a CD that doesn't CD, regardless of the CI. Don't try to be smarter than me. :) Report, Inform, Do my bidding regardless.
orthogonal
I had this on my buzzword bingo sheet for this google hangout.
This redundancy could be eliminated if the complexity of the system were increased to include the idea of a target, having multiple targets for a single environment.
This only matters for a deploy_on_green scenario with multiple environments. This would be a case where I would want DEPLOY_ONLY without testing. If I have two identical raspberry pi "environments" (but different deploy processes), I can TEST_AND_DEPLOY the commit to the first environment, and DEPLOY_ONLY to the second environment.
Is there already a way to test using a given language runtime in Strider? Wondering if this is something that can maybe be farmed out to pyenv, rbenv, nodenv, etc. with some caching so we don't have to rebuild the environment for a given version every time.
It seems like this is something that could be abstracted away in the language plugins as all the popular languages have tools for managing multiple versions.
@michaelmior plugins can do whatever they want. the environment phase is used for setting up language runtime, etc.
Plugins can also have a strider-wide cache, where they could hang on to the different language runtimes.
I see no activity on this issue since long, is there a plan to put this in ?
