FutoIn CID mimics what real human would do to start working on or for deploying some arbitrary project.
How it is done with README
Going back in the past, Developers and SysAdmins used to follow
README or similar
step-by-step environment preparation and application installation guides.
All such guidelines have quite common parts:
- Setup tools.
- Checkout from VCS or download & unpack binary artifact.
- (Optional) Run tools to install dependencies and build the project.
- Project-specific configuration steps.
- Setup system services to execute the project.
- (Optional) Setup of web server.
It was quite time consuming and error-prone. Infrastructure provisioning required custom coding for each case. Nowadays, containers mostly hide the problem of manual setup at cost of infrastructure complexity and some disadvantages like significantly increased network usage on image rebuild, lack of live-reload by design or still requirement for manual setup of host environment for development tools.
CID goes this route, if there is tool and action configuration in
How it is done without README
Many projects lack proper in-depth
README. Engineers have to analyze
source code or package to understand what technology is used and what are
common technology-specific steps to get the project up and running.
CID does exactly the same: unless there is a complete tool configuration in optional
file, FutoIn CID tries to auto-detect tools based on well-known files. For example, Git would be
detected based on
.git folder, npm would be detected based on
package.json, Composer would be
detected based on
composer.json and so on. Based on build tools, it’s possible to deduce what
kind of runtime environment has to be used.
Complex real-world scenario requires some hints and CID supports them through deployment configuration overrides. To be discussed in other sections.