They all run pretty much the same logic:
Submitter queues a job with some variable input (text, checkboxes)
and CCI logic is used to call FinalBuilder (passing the variables from the input form to FinalBuilder).
FinalBuilder does ALL the real heavy lifting for us (build, deploys, everything)
Now, say I want to add a feature to all of my configurations
For example: I want to add build tags according to the user input
So I added it in one of the configurations, and it works perfectly - we have build tags and everyone are happy
Now I want to copy this logic (green rectangle) to all of our ~40 configurations.
I want to copy the logic “as-is” exactly
The way I do it now is:
Open edit mode of ~40 configurations in ~40 chrome tabs(!!) and in each tab:
Create missing configuration scope variables in all configurations (if new variables are added for this logic, this is a must)
MANUALLY add and organize the required actions in the stage for each and every configuration.
(this takes at least 2 minutes to do, times 40 configurations - there goes ~2 hours)
This is absolutely tedious
Is there a better way of adding logic to a large number of configurations?
Unfortunately, there is no other way at the moment. We have previously had discussions about allowing stages to be based on templates, which could be edited at global or project level. I can’t give you any timescales on this though.
Why do you have several configurations with the same logic? I guess they each have a different repository?
The way we operate with FB8 / CCI is pretty much derived from these projects history.
Back in the day, my colleague Idan (Who I believe you are familiar with) has built and maintained monstrous FB6/7 projects for our build and deployment operations, these projects did and still do everything for us (build, pack, transfer, stop, backup, deploy, start, be able to choose 1 or more steps for a a list of various services with many optional flags and tweaks around).
Each such FB project has its own configuration xml files, they are a lot bigger and more complex than most FB projects you’ve encountered - i’m sure
These projects very generic nature gives us high flexibility with adding / editing or removing services from our environments - its all done through xml configuration files.
Even though the FB8 projects mostly run the same generic logic -
They are broken into separate projects based on the services each one is responsible for (backend services deployment, frontend services deployment, data warehouse services deployment, etc’ - each world of services has its own FB8 project that is used to deploy these services.
Since these projects have proven themselves over the years, and our deployment cycles are very stable - we continued with them and migrated them from FB7+FBServer to our current FB8+CCI combo.
CCI is currently being used only as a “web ui runner” for our FB8 projects, so multiple developers can deploy from one centralized location with security, logging/history, etc’)
===
Can you suggest a way to manually edit these changes via DB? (at my own risk)
(copy paste a bulk of newly added logic between configurations)
The actions of a single stage are stored in the database as JSON in the actions column of the builds_stagedefinition table. Individual actions are linked together by Next and FirstChild properties.
You can get the actions for a particular configuration using the following SQL:
SELECT p.name as ProjectName, c.name as ConfigName, sd.name as StageName, sd.actions FROM builds_stagedefinition sd
INNER JOIN builds_configurationversion cv ON sd.configurationversionid = cv.id
INNER JOIN builds_configuration c ON c.id = cv.configurationid AND c.latestconfigurationversionid = cv.id
INNER JOIN core_project p ON p.id = c.projectid
WHERE c.name = 'ConfigName' AND p.Name = 'ProjectName';
You may find it easier to use the Import/Export functionally in v1.9.2, which allows you to export all configurations in a project to a YAML or JSON file, which can then be edited and subsequently imported back into Continua CI.
Note that v1.9.2 is still in beta and remember to backup the database before making any changes.
