3. Operations (PM, CI-CD, Backup, Engineering)

Operations are the value-creating activities that transform the inputs into the final product.

Application deployment and operations required to build a software.

3.1. Project management

StratEx is a web application enabling Managers to control the delivery using customer’ processes enforced by conventions shared amongst the team members.

StratEx Data model

3.2. Software engineering

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?
  1. Can you use source control effectively?
  2. Can you solve algorithm-type problems?
  3. Can you program in more than one language or technology?
  4. Do you do something to increase your education or skills every day?
  5. Do you name things appropriately?
  6. Can you communicate your ideas effectively?
  7. Do you understand basic design patterns?
  8. Do you know how to debug effectively?
  9. Do you test your own code?
  10. Do you share your knowledge?
  11. Do you use the best tools for your job?
  12. Can you build an actual application?

3.3. Continous Integration-Continuous Delivery

CI/CD process by Team Foundation Service - credits: microsoft.com

Continous Integration vs. Continous Delivery vs. Continuous Development - credits : atlassian.com

3.3.1. Continuous Integration

Continuous Integration (CI) is straightforward and stands for continuous integration, a practice that focuses on making preparing a release easier. The acronym CD) can either mean continuous delivery or continuous deployment.

source : Continuous integration vs. continuous delivery vs. continuous deployment

digraph ContinousIntegration { #node [shape=rectangle, fontname="Sans"]; ratio="fill"; size="8.3,11.7!"; node [shape = polygon, sides = 4, distortion = "0.0", orientation = "0.0", skew = "0.0", color = white, style = filled, fontname = "Sans" ]; splines=true; nodesep=0.2; ranksep=0.5; linesep=2.0; margin=1.0; graph [overlap = false, margin=1.0]; # rankdir=LR; # overlap=false; # ratio=auto; label="Continous Integration v2019-04-27"; SourceCode [label="Source code" shape=invtrapezium color=orange]; MainBranch [label="Main branch" shape=invtrapezium color=orange1]; Build [label="Build" shape=invtrapezium color=orange2]; TestedBuild [label="Tested build" shape=invtrapezium color=orange]; SourceCode -> MainBranch [label=" Developers merge their changes back to the main branch as often as possible"]; MainBranch -> Build [label=" Developer's changes are validated by creating a build"]; Build -> TestedBuild [label=" Running automated tests against the build"]; }

3.3.2. Continuous Delivery

Continuous delivery (CD) is an extension of continuous integration to make sure that you can release new changes to your customers quickly in a sustainable way.

You automate your release process and deploy your application at any point of time by clicking on a button on a daily, weekly, fortnightly basis.

source : Continuous integration vs. continuous delivery vs. continuous deployment

3.3.3. Continuous Deployment

Continuous deployment (CD) implies that every change that passes all stages of your production pipeline is released to your customers. There’s no human intervention, and only a failed test will prevent a new change to be deployed to production.

source : Continuous integration vs. continuous delivery vs. continuous deployment

3.4. Backup

3.4.1. Which ressources do you need to backup?

  • Virtual machines running an Operating system (Windows, MacOSX, Linux…)
  • Databases (Microsoft SQL Server, MongoDB, Oracle Database, MySQL…)
  • File systems (Directories containing documents, images…)

3.4.2. Which strategy do you need to apply?

  • Store forever one full backup per year from January the 1st (Year Y1, Y2…)

  • Store everyday day one incremental backup for each resource

    • Store a full backup the first of each month
    • Store an incremental backup from Day 2 to the end of the month (31-1 backups)
    • Replace the incremental backup performed one month earlier (Month M-1)
    • Keep the full backup made once a month

3.4.3. Wrap up

  • Store in total :

    • 12 full backups per year for each month (1st day of each month)
    • 31 incremental backups for the last 31 days
    • 1 full backup per year
  • Example:

    • Year 1 : 12 + 31 backups
    • Year 2 : 12 + 31 + 1 backups
    • Year 3 : 12 + 31 + 2 backups