.. index:: Software Development .. _software development: Software Development ===================== https://en.wikipedia.org/wiki/Software_development https://en.wikipedia.org/wiki/Software_development_process https://en.wikipedia.org/wiki/Category:Software_design_patterns * ``_ * http://martinfowler.com/eaaCatalog/ * https://github.com/DovAmir/awesome-design-patterns * https://github.com/faif/python-patterns https://en.wikipedia.org/wiki/Software_engineering .. index:: CS .. index:: Computer Science .. _computer science: Computer Science ----------------- https://en.wikipedia.org/wiki/Computer_science#Applied_computer_science https://en.wikipedia.org/wiki/Outline_of_computer_science https://en.wikipedia.org/wiki/Category:Computer_science Topics: * ``_ * https://en.wikipedia.org/wiki/Category:Algorithms * :ref:`computer engineering` * :ref:`Data Structures` * :ref:`Operating Systems` * :ref:`software development` (*applied CS*) * :ref:`data science` (*applied CS*) * :ref:`knowledge engineering` (*applied CS*) * :ref:`Science` (*applied CS* with/for/on behalf of a domain) .. index:: Computer Science Curricula .. _computer science curricula: Computer Science Curricula +++++++++++++++++++++++++++ .. glossary:: Curricula + https://en.wikipedia.org/wiki/Curriculum + https://en.wikipedia.org/wiki/Open-source_curriculum + https://en.wikipedia.org/wiki/Open-source_curriculum#Resources Criteria + https://en.wikipedia.org/wiki/Criterion + ``__ + https://en.wikipedia.org/wiki/Information_criterion + "Common Criteria" -- :ref:`information security` platform specification + "Common Core" -- US education standard: https://en.wikipedia.org/wiki/Common_Core_State_Standards_Initiative + :ref:`business roi`, :ref:`is roi` Rubric + ``__ + A rubric can be expressed with a :ref:`matrix ` :ref:`data structure `. + A rubric can be expressed as an :ref:`RDF` :ref:`graph ` in e.g. :ref:`RDFa` or :ref:`JSON-LD`. Computer Science criteria, guidelines, and curricula: * ACM Computer Science Curricula 2013: Curriculum Guidelines for Undergraduate Degree Programs in Computer Science (December 20, 2013) https://www.acm.org/education/CS2013-final-report.pdf * AL -- Algorithms and Complexity (p.55) * AR -- Architecture and Organization (p.62) * CN -- Computational Science (p.68) * DS -- Discrete Structures (p.76) * GV -- Graphics and Visualization (p.82) * HCI -- Human-Computer Interaction (p.89) * IAS -- Information Assurance and Security (p.97) * IM -- Information Management (p.112) * IS -- Intelligent Systems (p.121) * NC -- Networking and Communication (p.130) * OS -- Operating Systems (p.135) * PBD -- Platform-Based Development (p.142) * PL -- Programming Languages (p.155) * SDF -- Software Development Fundamentals (p.167) * SE -- Software Engineering (p.172) * SF -- Systems Fundamentals (p.186) * SP -- Social Issues and Professional Practice (p.192) * ACM Computer Science Curriculum 2008: An Interim Revision of CS 2001 http://www.acm.org/education/curricula/ComputerScience2008.pdf * Programmer Competency Matrix http://sijinjoseph.com/programmer-competency-matrix/ https://competency-checklist.appspot.com/ https://github.com/hltbra/programmer-competency-checklist * computer science + data structures + algorithms + systems programming * software engineering + source code and version control + build automation + automated testing * programming + problem decomposition + systems decomposition + communication + code organization within a file + source tree organization + code readability + defensive coding + error handling + IDE + API + frameworks + requirements + scripting + database * knowledge + tool knowledge + languages exposed to + codebase knowledge + knowledge of upcoming technologies + platform internals + books + blogs * experience + languages with professional experience + platforms with professional experience + years of professional experience + domain knowledge .. index:: Computer Science Courses .. _computer science courses: Computer Science Courses ++++++++++++++++++++++++ * :ref:`education technology` > :ref:`Online Courses` * https://www.khanacademy.org/cs * https://www.class-central.com/subject/cs .. index:: Computer Science Exercises .. _computer science exercises: Computer Science Exercises +++++++++++++++++++++++++++ Exercises, Problems * http://rosettacode.org/wiki/Category:Programming_Tasks * :ref:`project euler` * :ref:`rosalind` .. index:: Code Golf .. _code golf: Code Golf ~~~~~~~~~~~ | Wikipedia: https://en.wikipedia.org/wiki/Code_golf * https://en.wikipedia.org/wiki/Code_golf#Tournaments_by_language .. index:: Project Management .. _project management: Project Management ------------------- | Wikipedia: https://en.wikipedia.org/wiki/Project_management | Awesome: https://github.com/shahedbd/awesome-project-management #Books * https://en.wikipedia.org/wiki/DMAIC * https://en.wikipedia.org/wiki/Kaizen * https://en.wikipedia.org/wiki/Systems_development_life_cycle * https://en.wikipedia.org/wiki/Software_project_management * https://en.wikipedia.org/wiki/Software_development_process .. index:: Waterfall .. _waterfall: Waterfall +++++++++++ | Wikipedia: https://en.wikipedia.org/wiki/Waterfall_model .. index:: Everyone Codes .. _everyone codes: Everyone Codes ++++++++++++++++ Q. Everyone? A. Everyone but: * :ref:`Code.org` .. index:: Agile .. _agile: Agile +++++++ | Wikipedia: https://en.wikipedia.org/wiki/Agile_software_development * https://en.wikipedia.org/wiki/Lean_software_development * http://epf.eclipse.org/wikis/epfpractices/ * http://agilemodeling.com/essays/bestPractices.htm .. index:: Stand Up Meeting .. _stand up meeting: Stand Up Meeting ~~~~~~~~~~~~~~~~~ | Wikipedia: https://en.wikipedia.org/wiki/Stand-up_meeting * ``_ .. note:: Meeting participants need not actually stand; as in a :ref:`Digital Stand Up Meeting`. .. index:: Three Questions .. _three questions: Three Questions ````````````````` | Wikipedia: https://en.wikipedia.org/wiki/Stand-up_meeting#Three_Questions 1. What did I accomplish yesterday? (What have I accomplished "Since" our last meeting) 2. What will I do today? (What do I plan to be working on "Until" we meet next) 3. What obstacles are impeding my progress? ("Obstacles") An alternative form of the three questions: "Since", "Until", "Obstacles": .. code:: markdown # team/project ## yyyy-mm-dd ### @username #### Since #### Until #### Obstacles .. index:: Digital Stand Up Meeting .. _digital stand up meeting: Digital Stand Up Meeting ``````````````````````````` A Digital :ref:`Stand Up Meeting` is a meeting conducted through digital means of communication; rather than through traditional in-person communication. Pros: * **Links**: Realtime collaborative documents (*live docs*), team chat logs, and issue/ticket comment threads have URIs, are easier to remember, and more to the point. * Easier to prepare for * More time to read, think, and respond * More comfortable * Easier to get up to date with Cons: - It's not everyone in the same room - "Shouldn't this all be in the issue tracker?" * Mailing Lists, Forums, :ref:`SIOC` <- Links to source, docs, issues * Bugs, User Stories -> Issue Tracker * Daily Stand Up Meeting log / **minutes** -> * Digital Stand Up Meeting Process Checklist: - [ ] Create a collaboratively edited document ("live doc", "doc") * Realtime collaborative editors: Etherpad Lite, Google Docs * An example of :ref:`Three Questions` for stand up meetings (in :ref:`Markdown`, with :term:`URIs `, for GitHub, BitBucket): .. code:: # team-name/project-name Daily Stand Up Log ## 2015-01-01 ### @username1 1. since: #1, #2, http:// 2. until: #2 3. obstacles: - ### @username2 1. since: #3, #2, https:// 2. until: #2 3. obstacles: - - [ ] Share the link to the live doc with the team - [ ] Email, Text Chat - [ ] Meeting/event invitations (iCal) * [ ] Chat (Text, Voice, Video) * Text * :ref:`Slack` * :ref:`Mattermost` * HipChat * Gitter * :ref:`XMPP` * :ref:`IRC` * Voice/Video (cross-platform): Google Hangouts, Skype, Cisco WebEx, :ref:`WebRTC` * Live streaming * YouTube * Twitter * Facebook See: :ref:`team building` (:ref:`The same page`, :ref:`Collaborative software`) .. index:: Extreme Programming .. index:: XP .. _XP: Extreme Programming ~~~~~~~~~~~~~~~~~~~~ | Wikipedia: https://en.wikipedia.org/wiki/Extreme_programming | EPFWiki: http://epf.eclipse.org/wikis/xp/ .. index:: Unified Process .. index:: RUP .. index:: OpenUp .. index:: UP .. _unified-process: Unified Process ~~~~~~~~~~~~~~~~~ | Wikipedia: https://en.wikipedia.org/wiki/Unified_Process | EPFWiki: http://epf.eclipse.org/wikis/openup/ * "Rational Unified Process" (RUP) * OpenUP is an :ref:`open source` Unified Process .. index:: Scrum .. _scrum: Scrum ~~~~~~~ | Wikipedia: ``_ | EPFWiki: http://epf.eclipse.org/wikis/scrum/ * The Daily Scrum (EPF Wiki Entry) http://epf.eclipse.org/wikis/scrum/Scrum/tasks/the_daily_scrum_C8FB7908.html .. index:: Software Development Effort Estimation .. index:: Effort Estimation .. index:: Planning Poker .. _effort estimation: Effort Estimation ~~~~~~~~~~~~~~~~~~~ | Wikipedia: https://en.wikipedia.org/wiki/Software_development_effort_estimation .. index:: Planning Poker .. _planning poker: Planning Poker ~~~~~~~~~~~~~~~~ | Wikipedia: https://en.wikipedia.org/wiki/Planning_poker .. index:: Kanban .. _kanban: Kanban ~~~~~~~ | Wikipedia: https://en.wikipedia.org/wiki/Kanban | Wikipedia: ``_ * GitHub and Kanban: * https://waffle.io * https://taiga.io (https://github.com/taigaio) .. index:: Requirements Management .. _requirements management: Requirements Management ------------------------- | Wikipedia: https://en.wikipedia.org/wiki/Requirements_management .. index:: Requirements Modeling .. _requirements modeling: Requirements Modeling ++++++++++++++++++++++++ | Wikipedia: https://en.wikipedia.org/wiki/Requirements_analysis .. index:: Agile Modeling .. _agile modeling: Agile Modeling ++++++++++++++++ | Wikipedia: https://en.wikipedia.org/wiki/Agile_modeling | Docs: * "Agile Modeling Best Practices" http://agilemodeling.com/essays/bestPractices.htm * **Model storming**: http://agilemodeling.com/essays/modelStorming.htm * JIT: Just-in-time * BRUF: "Big Requirements Up Front" * JBGE: "Just Barely Good Enough" (/``anticipation``) * **Executable Specifications**: http://agilemodeling.com/essays/executableSpecifications.htm * TST: :ref:`TDD` and :ref:`BDD` tests (:ref:`Test Automation`) * BLD: :ref:`Software Packaging ` * BLD: :ref:`Configuration Management` (*Infrastructure as Code*) * BLD: :ref:`Continuous Integration` (*one-click build*) * BLD: :ref:`Continuous Deployment` (*one-click deploy*) See also: * :ref:`Scrum`, :ref:`Extreme Programming`, :ref:`Unified Process` * :ref:`collaborative software` * :ref:`six patterns of collaboration` .. index:: Test Driven Development .. index:: TDD .. _tdd: .. _test-driven-development: Test Driven Development ~~~~~~~~~~~~~~~~~~~~~~~~ | Wikipedia https://en.wikipedia.org/wiki/Test-driven_development * https://westurner.github.io/wiki/awesome-python-testing * https://westurner.github.io/wiki/awesome-python-testing#workflow-evolution * https://westurner.github.io/wiki/awesome-python-testing#test-driven-development-tdd .. index:: Behavior Driven Development .. index:: BDD .. _bdd: .. _behavior driven development: Behavior Driven Development ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Wikipedia: https://en.wikipedia.org/wiki/Behavior-driven_development * https://westurner.github.io/wiki/awesome-python-testing#behavior-driven-development-bdd .. index:: Given-When-Then .. _given-when-then: Given-When-Then `````````````````` | Wikipedia: https://en.wikipedia.org/wiki/Given-When-Then * Given (context) * When (event) * Then (expect, should, assert) .. list-table:: * - Given When Then - Given - When - Then * - :ref:`Hoare Logic` - precondition ``P`` - command ``C`` - postcondition ``Q`` * - Terms - Input: State, Context (,RDF), Database - Input: Parametrized Event, Message - Output Conditions, Rules, Expressions, Assertions, Expectations * - HTTP 1.1 - app state (etc, fs, db) - request (URI(URN|URL))?attrs=values - response ({json: True}) * - Channels - app state (etc, fs, db) - event(message_in) - conditions(message_out) * - Vows - test suite, ``@Vows.Batch``, ``Vows.Context``, ``topic()`` - vow -- ``def should_quack(self, topic):`` - vow -- ``expect(topic.quack()).to_equal(value)`` .. index:: User Story .. _user story: User Story ~~~~~~~~~~~~ | Wikipedia: https://en.wikipedia.org/wiki/User_story A user story is a couple of simple sentences expressing desired competencies, features, or behaviors of a system. Ideally, user stories can simply be transformed to e.g. :ref:`TDD ` and :ref:`BDD ` tests. Example user stories: * "[role] can [action [objects]] [in order to / so that [...]]" * "Users can login and post Things with a description and a url" * "Users can login and post Things with a description and a url in order to have something with a URL to share" * "Users can share shared Things with a URL" * User story formats https://en.wikipedia.org/wiki/User_story#Format .. index:: Three C's .. _3cs: .. _three c's: Card, Conversation, Confirmation `````````````````````````````````` | Wikipedia: https://en.wikipedia.org/wiki/User_story#History | Docs: http://ronjeffries.com/xprog/articles/expcardconversationconfirmation/ The Three C's of :ref:`User story` :ref:`requirements modeling` are **Card**, **Conversation**, and **Confirmation**. * Card * Issue ``name`` and ``description`` (or ``description__markdown_github``). * :ref:`Codelabels` * Conversation * Issue comment thread or **threads** (with full URLs) * Pull Request comment thread or **threads** (with full URLs) * :ref:`Codelabels` * Confirmation * Issue ``status``: open / closed * Issue Labels: { duplicate, wontftix } * Issue labels: { ready, in progress, } TODO * https://waffle.io/ uses ready, in progress labels to build an interactive :ref:`Kanban` board with columns from github issue labels. .. index:: Use Case .. _use case: Use Case ~~~~~~~~~~ | Wikipedia: https://en.wikipedia.org/wiki/Use_case A use case describes actions, actors, and goals. * :ref:`UML` defines a formal model for :ref:`Use cases ` and use case diagrams. * Use case diagrams may involve **stick figures** as symbols for **actors**. * In practice, the use case is a more formal requirement model than the :ref:`user story`. * In terms of process workflow, a :ref:`Use Cases ` could be derived from zero or more :ref:`User Stories `. * There are many :ref:`domain modeling` tools for e.g. :ref:`UML`; each with various levels of support for *round-trip* between modeling tool and e.g. code that you add after transforming to which is sometimes referred to as *stub* code. .. index:: Requirements Traceability .. _requirements traceability: Requirements Traceability +++++++++++++++++++++++++++ | Wikipedia: https://en.wikipedia.org/wiki/Requirements_traceability * :term:`URLs ` * issue numbers (GitHub, BitBucket, ): * ad-hoc (the numbers probably won't be sequential) * issue ``#1``: Mission, Project list * issue ``#2``: Project * issue ``#3``: Goal * issue ``#4``: an Objective for goal ``#3`` * With a fixed, preallocated numbering system, this would be e.g. ``project:3.1``; however, issue ticket numbers are sequential by order of creation * the numbers would then appear somewhat arbitrary * there would be no need to renumber things * ``#perma-link`` document :term:`URL` fragments * ``#mission-statement`` * ``#project-`` / ``#p-`` * ``#goal-`` / ``#g-`` * ``#objective-`` / ``#o-`` * implementations: * :ref:`sphinx` :ref:`restructuredtext` (with Ctrl-F'able explicit links): * https://docs.python.org/devguide/documenting.html#sections .. code:: rst .. _mission: ######### Mission ######### .. _project-name: *************** Project: Name *************** .. _goal-name: Goal: Name =============== .. _objective-name: Objective: Name ---------------- * [ ] Task: Name .. _task-name: Task: Name ^^^^^^^^^^^^ * :ref:`markdown`: .. code:: markdown # Mission: ## Project: Name ## Goal: Name ### Objective: Name * [ ] Task: Name #### Task: Name * see also: ``#pyglobalgoals`` * https://github.com/schemaorg/schemaorg/issues/1127 * \[ ] ``schema:Project`` * \[ ] ``schema:Goal`` * \[ ] ``schema:Objective`` * \[ ] ``schema:Task`` * :ref:`codelabels`:: MISSION GOAL OBJECTIVE IDEA: idea STRY: user story -> TST, ENH, BUG, RLS ; -> CASE ; + REQ CASE: use case -> TST, ENH, BUG, RLS ; -> STRY ; + REQ REQ: requirement -> TST ; + REQ SPRINT: sprint == { REQ, CASE, STRY, TST, BUG, ENH, DOC, TST, RLS } TASK .. index:: Work Breakdown Structure .. _work breakdown structure: Work Breakdown Structure ~~~~~~~~~~~~~~~~~~~~~~~~~~ | Wikipedia: https://en.wikipedia.org/wiki/Work_breakdown_structure .. index:: Mission .. _mission: Mission ```````` | Wikipedia: https://en.wikipedia.org/wiki/Mission_statement .. index:: Project .. _project: ======== Project ======== | Wikipedia: https://en.wikipedia.org/wiki/Project * ``__ .. index:: Goal .. _goal: ------- Goal ------- | Wikpedia: https://en.wikipedia.org/wiki/Goal * https://en.wikipedia.org/wiki/Goal_setting .. index:: SMART .. _smart criteria: .. _smart: SMART ****** | Wikipedia: https://en.wikipedia.org/wiki/SMART_criteria * Specific * Measurable * Attainable * Relevant * Time-bound .. index:: Objective Objective *********** | Wikipedia: https://en.wikipedia.org/wiki/OKR * https://en.wikipedia.org/wiki/Management_by_objectives * :ref:`SMART` Checkboxes ~~~~~~~~~~~~~~ | Wikipedia: https://en.wikipedia.org/wiki/Checkbox Checkboxes can be expressed in plaintext with square brackets surrounding a space character, a state character, or a completion character (e.g. lowercase ``x`` or uppercase ``X``). A :ref:`Markdown` list of items with checkboxes and :ref:`codelabels`: .. code:: markdown - [x] ENH: one **bold** - [ ] ENH: two *italic* - [x] TST: two.one - [ ] DOC: two.two \* two - [ ] RLS: ``three`` (also `three`) A :ref:`ReStructuredText` list of items with checkboxes and :ref:`codelabels`: .. code:: restructuredtext * [x] ENH: one **bold** * [ ] ENH: two *italic* * [x] TST: two.one * [ ] DOC: two.two \* two * [ ] RLS: ``three`` TODO :: * [ ] Unchecked # github * [x] Checked # github * [X] Checked # github - [X (YYYY-MM-DD HH:MM:SS)] - [-] - [o] - [O] - [[ ]] # text - [[x]] # text - [[o]] # text - \\[ ] # text - \\[-] # text - \\[o] # text - \\[x] # text - \\[X] # text .. index:: Codelabels .. _code-labels: .. _code labels: .. _codelabels: Codelabels ~~~~~~~~~~~~ Codelabels (*code labels*) are three-letter codes with which commit messages can be prefixed. :: CODE Label color name background text ---- -------------- --------------- ---------- ------- BLD build light green #bfe5bf #2a332a BUG bug red #fc2929 #ffffff (github default) CLN cleanup light yellow #fef2c0 #333026 DOC documentation light blue #c7def8 #282d33 ENH enhancement blue #84b6eb #1c2733 (github default) ETC config PRF performance deep purple #5319e7 #ffffff REF refactor dark green #009800 #ffffff RLS release dark blue #0052cc #ffffff SEC security orange #eb6420 #ffffff TST test light purple #d4c5f9 #2b2833 UBY usability light pink #f7c6c7 #332829 DAT data SCH schema REQ requirement ANN announcement # Workflow Labels (e.g. for waffle.io kanban board columns) ready dark sea green #006b75 #ffffff in progress yellow #fbca04 #332900 # GitHub Labels duplicate darker gray #cccccc #333333 (github default) help wanted green #159818 #ffffff (github default) invalid light gray #e6e6e6 #333333 (github default) question fuschia #cc317c #ffffff (github default) wontfix white #ffffff #333333 (github default) Note: All of these color codes (except for fuschia) are drawn from the default GitHub palette. Note: There are 23 labels listed here. .. note:: For examples with color swatches in alphabetical order, see https://github.com/westurner/dotfiles/labels Codelabel Syntax ``````````````````` :: BLD: Makefile: default -> test BUG: setup.py: fix console_entrypoints CLN: .gitignore: add "'pattern' DOC: index.rst: add readme.rst to TOC ENH: app/app.py: print 'Hello World' (closes #1) PRF,REF: app/app.py: factor out of a loop REF: app/app.py: extract into class and @staticmethods RLS: setup.py,VERSION.txt,app/app.py: app v0.0.1 SEC: app/app.py: pass lists/tuples to sarge.run (#2) TST: Extend tests for #1 UBY: app/app.py: update _('strings') DAT: data/filename.csvw.jsonld: added, updated SCH: data/context.jsonld: added, updated * ``COMMA,DELIMITED, SET: of prefix labels`` * ``THR`` - Three-characters (code labels) Code labels are helpful for: * DOC: working with issue tracking tagging and labeling systems * DOC: aggregating changes into release logs (``HISTORY``) * DOC: correlating changes with requirements (https://en.wikipedia.org/wiki/Requirements_traceability) [`Requirements Traceability`_] .. note:: These code labels are adapted and extended from a previous version of the `pandas/CONTRIBUTING.md `_ .. index:: Technical Debt .. _technical debt: Technical Debt ---------------- | Wikipedia: https://en.wikipedia.org/wiki/Technical_debt * https://en.wikipedia.org/wiki/Technical_debt#Causes * :ref:`Refactoring` can reduce :ref:`Technical Debt`. .. index:: Refactoring .. _refactoring: Refactoring ------------- | Wikipedia: https://en.wikipedia.org/wiki/Code_refactoring * :ref:`tdd` and :ref:`continuous integration` are key to "Fearless Refactoring". * :ref:`Refactoring` can reduce :ref:`Technical Debt`. * While syntactical eloquence and/or elegance in one or more languages can be learned through :ref:`Code Golf`, practical :ref:`refactoring` is more about structural, architectural decisions which anticipate change. .. index:: Continuous Delivery .. index:: CD .. _continuous delivery: Continuous Delivery --------------------- | Wikipedia: https://en.wikipedia.org/wiki/Continuous_delivery * https://en.wikipedia.org/wiki/Application_lifecycle_management * US Digital Services Playbook https://playbook.cio.gov/ * https://westurner.github.io/opengov/us/us-digital-services-playbook .. index:: Revision Control .. index:: Version Control .. index:: VCS .. index:: RCS .. _revision control: Revision Control ++++++++++++++++++ | Wikipedia: https://en.wikipedia.org/wiki/Revision_control | Docs: :ref:`Tools > Version Control Systems ` Revision control, or *version control*, is a change management strategy for a project repository. * There is a better way than emailing which version of what the attachment was named before the re: subject line changed. * folders * file versions * usernames, change logs, signatures * A *Revision Control System* (RCS) or *Version Control System* (VCS) is a software solution for handling change management with one or more project repositories. * Centralized :ref:`Revision Control` Systems (RCS, VCS): * :ref:`CVS`, :ref:`SVN ` * :ref:`Distributed Revision Control ` Systems (DVCS): * :ref:`Git`, :ref:`Mercurial`, :ref:`Bazaar` .. index:: Distributed Revision Control .. index:: DVCS .. _dvcs: Distributed Version Control ++++++++++++++++++++++++++++++ | Wikipedia: https://en.wikipedia.org/wiki/Distributed_revision_control Distributed Revision Control Systems ("DVCS") are :ref:`version control ` systems designed for backup redundancy and collaboration. * http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ * :ref:`Git`, :ref:`Mercurial`, :ref:`Bazaar` * :ref:`vcs` (:ref:`Git`, :ref:`HubFlow`, :ref:`Mercurial`) .. index:: Bisection .. _bisection: Bisection ~~~~~~~~~~~ | Wikipedia: ``_ Bisection is a method for determining which change causes a fault (or a specific test to change from passing to failing or vice-versa). Many bisection algorithms take a start and end ("between here and here") and do a binary search ("this half or that half"); checking out each revision and running a script that should return ``0`` for OK, or non-zero. Code bisection with :ref:`git`: * https://www.kernel.org/pub/software/scm/git/docs/git-bisect.html * https://www.kernel.org/pub/software/scm/git/docs/git-blame.html * http://git-scm.com/book/en/Git-Tools-Debugging-with-Git Code bisection with :ref:`mercurial`: * http://www.selenic.com/mercurial/hg.1.html#bisect * http://www.selenic.com/mercurial/hg.1.html#annotate * http://hgbook.red-bean.com/read/finding-and-fixing-mistakes.html#sec:undo:bisect .. index:: Branching & Merging .. _branching and merging: Branching & Merging ~~~~~~~~~~~~~~~~~~~~~ | Wikipedia: ``_ | Wikipedia: ``_ * http://www.infoq.com/articles/agile-version-control * :ref:`HubFlow` -- a :ref:`Git` release workflow for GitHub and *Pull Requests* with always-stable ("firm") ``master`` and ``develop`` branches, and ``hotfix/``, ``feature/``, and ``release/`` branches; consistently woven. .. index:: Test Automation .. _test automation: Test Automation +++++++++++++++++ | Wikipedia: https://en.wikipedia.org/wiki/Test_automation * :ref:`Test Driven Development ` -- write tests for bugs, use cases, user stories, features, workflows, changes. * :ref:`Continuous Integration` -- always run the tests when checking code into :ref:`revision control` and *before releasing*. * :ref:`Continuous Delivery` -- test the application delivery and deployment (script a complete system install e.g. with :ref:`virtualization` like :ref:`Docker`). .. index:: Continuous Integration .. index:: CI .. _continuous integration: Continuous Integration ++++++++++++++++++++++++ | Wikipedia: https://en.wikipedia.org/wiki/Continuous_integration * :ref:`Test Automation` * :ref:`Configuration Management` * #DevOps .. index:: Continuous Deployment .. _continuous deployment: Continuous Deployment +++++++++++++++++++++++ | Wikipedia: https://en.wikipedia.org/wiki/Continuous_deployment * :ref:`Configuration Management` * :ref:`Virtualization` * #DevOps