John Louros

A well defined development process is key for a successful Software Development team. Transparency and common understanding, will help new developers get up to speed more quickly and allow more flexibility for further modifications. This may sound a bit chaotic, but your development process should be prepared to allow constant improvements (modifications). Obviously you shouldn't change something just for the sake of it; identify what value does your modification bring and make a conscious decision before applying it; ask your team members, or even the whole department, what do they think about your change and how it will help them; also, things that look obvious to you, might not seem so obvious to someone else, so think about the impact your tweak will have on your team workflow. What I am saying can be interpreted as common sense, and it should be, however you would be amazed by how often people disregard common sense. And I can tell you, changing something without a reason can be as dangerous as not changing at all.

A fundamental concept, for a well defined development process you must: identify all the requirements; gather information about the used tools and components; what does the team should aim for; what's the expected action when a particular event occurs. This exercise helps to set expectations, or more simplistically helps you identify what question must be answered: "does my code build?", "all the unit tests pass?", "am I able to deploy this code?", "does my code meet the stakeholders exceptions?", so on.

Today I want to share a example set of requirements, components, tools and concepts you should aim for. Actions and steps require a more involved analysis and it deserves a post of their own. Meanwhile here's a simplified guideline you can follow:

Requirements:

• all tests must pass
• existing tests can't be ignored
• test code coverage shouldn't drop
• new code follows the defined coding standards
• technical debt should not increase
• all applications should be properly versioned
• set versions should use the same conventions
• new code was properly reviewed and approved
• modifications don't create new security issues
• an application package is unique and should be built only once
• an application should only have one build/package process
• tasks, issues or any work items must be associated with the corresponding "changeset"
• application performance should meet the defined standards
• every team should use the same workflow (i.e.: git-flow)
• the defined process should be enforced by default and prevent any workarounds

Components:

• version control system
• version control system repository
• integrated development environment (IDE)
• build controller
  • build agents
• build artifact repository
• deployment manager
  • deployment agent
• virtualization manager
• feature management system
• issue tracking system
• code review system
• test execution system
• performance measuring tools

Tools:

• git
• GitHub
• reviewboard
• Visual Studio
• ReSharper
• Jenkins
• Artifactory
• SonarQube
• Go (ThoughtWorks)
• Confluence
• JIRA
• MS System Center
• YSlow
• OWAP Zap
• HipChat

Aim for:

• consistent application versioning
  • all application must be versioned
  • use the same schema to generate versions (ex: 2015.02.25.2) #{Year}.{Month}.{Day}.{Build counter}
• applications must be independently deployable. Reject any hardcoded environment settings
• use the exactly the same package on any environment. Build once, use the same binaries on Dev, QA, Staging, Production environments.
• each application should be built using the same build process/build definition. Do not break it down to a build definition for each branch. If you want to tweak the process, you just have to change it in one place. Avoid unnecessary complexity.
• each "changeset" must be associated with a correspondent task. This way the company can easily track the investment and maintenance cost of a particular feature.
• try to keep a consistent set of tools. Avoid multiple different build controllers or issue tracking systems. Whatever tools were picked, keep them and if you need to change it, do it across the board.
• clear and transparent process. Everyone should have a easy way to view the entire process workflow and the current state of the process. If the team is waiting on an approval, who should they contact.
• enforced and automated workflow. A well defined process is great, but it's even better is you can automate it. Wikis are a great place for documentation, they can't enforce a particular workflow. Use proper tools to manage your workflow.