Category: Agile Articles

DevOps and Benefits of DevOps

DevOps

Under a DevOps model, development and operations teams are no longer “siloed.”

Quality assurance and security teams may also become more tightly integrated with development and operations and throughout the application lifecycle

DevOps has come the new methods of Continuous Integration, Continuous Delivery, (CI/CD) and Continuous Deployment. 

Benefits of DevOps

Speed

Move at higher velocity

Rapid Delivery

Increase the frequency and pace of releases 

Reliability

Ensure the quality of application updates and infrastructure changes s

Scale

Operate and manage your infrastructure and development processes at scale. 

Improved Collaboration

Developers and operations teams collaborate closely, share many responsibilities, and combine their workflows. This reduces inefficiencies and saves time (e.g. reduced handover periods between developers and operations, writing code that takes into account the environment in which it is run).

Security

Move quickly while retaining control and preserving compliance. 


Continuous Integration (CI)

Continuous Integration (CI)


Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.
By integrating regularly, you can detect errors quickly, and locate them more easily.
Solve problems quickly
Because you’re integrating so frequently, there is significantly less back-tracking to discover where things went wrong, so you can spend more time building features.
Continuous Integration is cheap. Not continuously integrating is costly. If you don’t follow a continuous approach, you’ll have longer periods between integrations. This makes it exponentially more difficult to find and fix problems. Such integration problems can easily knock a project off-schedule, or cause it to fail altogether.
Continuous Integration brings multiple benefits to your organization:
·        Say goodbye to long and tense integrations
·        Increase visibility which enables greater communication
·        Catch issues fast and nip them in the bud
·        Spend less time debugging and more time adding features
·        Proceed in the confidence you’re building on a solid foundation
·        Stop waiting to find out if your code’s going to work
·        Reduce integration problems allowing you to deliver software more rapidly

More than a process

Continuous Integration is backed by several important principles and practices.

The Practices

·        Maintain a single source repository
·        Automate the build
·        Make your build self-testing
·        Every commit should build on an integration machine
·        Keep the build fast
·        Test in a clone of the production environment
·        Make it easy for anyone to get the latest executable
·        Everyone can see what’s happening
·        Automate deployment

How to do it

·        Developers check out code into their private workspaces.
·        When done, commit the changes to the repository.
·        The CI server monitors the repository and checks out changes when they occur.
·        The CI server builds the system and runs unit and integration tests.
·        The CI server releases deployable artefacts for testing.
·        The CI server assigns a build label to the version of the code it just built.
·        The CI server informs the team of the successful build.
·        If the build or tests fail, the CI server alerts the team.
·        The team fix the issue at the earliest opportunity.
·        Continue to continually integrate and test throughout the project.

Team Responsibilities

·        Check in frequently
·        Don’t check in broken code
·        Don’t check in untested code
·        Don’t check in when the build is broken
·        Don’t go home after checking in until the system builds
Many teams develop rituals around these policies, meaning the teams effectively manage themselves, removing the need to enforce policies from on high.

Continuous Deployment

Continuous Deployment is closely related to Continuous Integration and refers to the release into production of software that passes the automated tests.
Essentially, “it is the practice of releasing every good build to users,” explains Jez Humble, author of Continuous Delivery.
By adopting both Continuous Integration and Continuous Deployment, you not only reduce risks and catch bugs quickly, but also move rapidly to working software.

With low-risk releases, you can quickly adapt to business requirements and user needs. This allows for greater collaboration between ops and delivery, fuelling real change in your organisation, and turning your release process into a business advantage.

POINTS to KEEP in MIND DURING AGILE ESTIMATION – Planning Poker

POINTS to KEEP in MIND DURING AGILE ESTIMATION – Planning Poker

  1. All developers in the team should participate in planning poker.
  2. Each person involved in estimation should be given a deck of cards at beginning of planning poker estimation meeting. Each card should have valid estimates. Cards can have serial number ( 1,2,3,4,5,..etc ) or Fibonacci numbers ( 1,2,3,5,8,13..etc) or Tshirt sizing ( S,M,L,XL,XLL )
  3. Prepared card can be reused in other planning poker estimation meeting.
  4. Product owner or business analyst or user story creator reads out user story.
  5. Product owner or business analyst or user story creator answers any questions that developers asks.
  6. There might be disagreement among estimators on user story points.So, people having such disagreements explain their points. Then estimators are asked to estimate again.

RallyDev – Addition of new Schedule State of User stories / Defects

RallyDev – Addition of new Schedule State of User stories / Defects

  1. Login as Workspace Administrator.
  2. Click the setup icon in the upper right corner of Rally.
  3. Click the Workspaces & Projects link.
  4. Click on the name of your workspace
  5. Click the Fields link that appears in the left sidebar
  6. Click the gear icon to the left of the Schedule State field and select Edit.
  7. Select the Custom 1 value by clicking on it in the Drop Down List Values box.
  8. Change the value in the Value field.
  9. Change the value in the Legend field.
  10. Check the check box next to the Enabled field.
  11. Click on the green Actions checkmark.
  12. Save your changes.

Note below :

 
  1. It can only have six values, two of which may be hidden and/or customized.
  2. Four of the values are non-modifiable (they cannot be edited or disabled):    
  •         Defined
  •         In-Progress
  •         Completed
  •         Accepted
 

Agile Methodology & Extreme Programming

Agile Methodology

Agile methodologies advocates the following:

  • Small Releases: The release times typically are a 2-4 weeks. These releases of software may not have the full functionality. But they are complete and should be usable.

  • Evolutionary Design: as opposed to Upfront design.

  • Sufficient documentation: without overloading of developers.

  • Continuous Integration: The code needs to be built and integrated into the build machine consistently. (scheduled builds)

  • Automated testing: Tests to be automatically run to make sure that the code does not break existing functionality using NUnit etc. 

  • Document generation from code: The best way to keep the documents complete and up to date is to generate them automatically from code. This of course requires well established regulations and coding standards so that the documentation can be automatically generated by the tools.

Extreme Programming

Extreme programming is the most extreme form of agile methodology. This brings its own additional thoughts such as:

  • Test Driven or Test First Programming: The tests are written before a single line of code is written. The objective of the code is to make the tests pass. So no code can get ever written unless there is a failed test.

  • YAGNI: (You ain’t gonna need it) Don’t code for features that are not listed in the current requirements. The reasons preached are:

 

    • The requirements are not known at this stage and hence these features even if coded today would not be coded correctly.

 

    • This takes cycles away from the time spent on the requested features.

  • Pair programming: Programmers code in pairs so that a senior programmer trains a novice programmer in the process. This way the knowledge is spread across the group rather than staying with a person (expert).