Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
S
slapos.buildout
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
8
Merge Requests
8
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
nexedi
slapos.buildout
Commits
a3a349e1
Commit
a3a349e1
authored
Feb 11, 2017
by
Jim Fulton
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Try to exlain why people should care.
parent
ff714286
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
76 additions
and
3 deletions
+76
-3
doc/index.rst
doc/index.rst
+76
-3
No files found.
doc/index.rst
View file @
a3a349e1
==============================================
Buildout, an automation tool written in Python
==============================================
================================================================
Buildout, an automation tool written in and extended with Python
================================================================
Buildout is a tool for automating software assembly.
- Run build tools to build software.
- Apply software and templates to generate configuration files and scripts.
- Applicable to all software phases, from development to production deployment.
- Based on **core principles**:
- Repeatability
- Componentization
- Automation
Repeatability
=============
It's important that given a project configuration, two checkouts of the
configuration in the same environment (operating system, Python
version) should produce the same result, regardless of their history.
For example, is someone has been working on a project for a long time,
and has committed their changes to a version control system, they
should be able tell a colleague to check out their project and run
buildout and the resulting build should have the same result as the
build in the original working area.
Componentization
================
We believe that software should be self contained, or at least, that
it should be possible. The tools for satisfying the software
responsibilities should largely reside within the software project
itself.
Some examples:
- Software services should include tools for monitoring them.
Operations, including monitoring is a software responsibility,
because the creators of the software are the ones who know best how
to assess whether it is operating correctly.
It should be possible, when deploying production software, for the
software to configure the monitoring system to monitor the software.
- Software should provide facilities to automate it's configuration.
It shouldn't be necessary for people to create separate
configuration whether it be in development or deployment (or stages
in between).
Automation
==========
Software deployment should be highly automated. It should be possible
to checkout a project and with a single simple command (or two), get a
working system. This is necessary to achieve the goals of
repeatability and componentization and generally not to waste people's
time.
Learning more
=============
Learn more:
- :doc:`Getting started <getting-started>`
- :doc:`Topics <topics/index>`
- :doc:`Reference <reference>`
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment