Common Website Mistakes 6: Misconceptions in the Development Cycle

In web development, most companies have a adapted an agile approach. Since such an approach requires feedback loops of inspection and adaption, the IT departments have set up multiple environments to support the agile delivery process. There is often a lot of confusion about these stages, so I want to describe what they are for.

Common stages

There is a widespread set of stages, each of which has a specific role in the development cycle. Although names often differ and some environments might be omitted under certain circumstances, the main purposes for each environment should be uniform across all companies. The main goals of having these environments are:

• Preventing faulty features from getting to production
• Enabling developers to work as efficiently as possible
• Delegating accountability by providing approval mechanisms

The production line: Developer machines

The first working version of every feature exists on the computer of a developer. It is an isolated copy of the solution and makes sure that each developer can work without affecting other developers. Business users normally do not see these versions, albeit they might be occasionally presented to show progress or demonstrate design ideas.

• Synonyms: local, dev, developer, VM
• Deployment cycle: Changes all the time
• Availability: Sporadic
• Who uses it: The developer

Common Misconceptions

What you see here is not necessarily working functionality - it might be using fake data or even just be a mock to visualize how the feature could look like.

Bringing it all together: Integration

Since a development team consists of multiple developers that are working on independent copies of the solution, there must be a step of integrating the changes into a combined version. This version is not on a developer's machine anymore, instead it is a central system, often with down-scaled hardware to save costs.

• Synonyms: dev, sit, play, int
• Deployment cycle: Changes at least once a day
• Availability: More than 50%
• Who uses it: Developers, product owners, feature requester

Common Misconceptions

What you see here should be a fairly complete version of single features, but interactions between those features might be broken and content might heavily deviate. It often contains edge-case-content like extremely long texts and huge images, as well as some debugging functionality.

Verifying the result: Test

Once a development team is certain that a feature technically works, they will promote it to the test environment. The test environment mirrors the production system very closely and is typically visible throughout the whole company. It allows stakeholders to verify the solution and sign-off that it fulfills the business requirements and works as intended.

• Synonyms: uat, test, stage, staging, signoff
• Deployment cycle: Same as production
• Availability: Close to production
• Who uses it: Feature requester, stakeholders, product owners

Common Misconceptions

All features should be thoroughly tested and production-ready. Pull a feature that reached this stage should be an exception. Note that there are often no mechanisms in place to migrate content from here to production. In other words: The effort you invest here might be in vain.

The one and only: Production

Production should be pretty clear to everyone and is the last stage of every feature. It is now available to the public and can not easily be rolled back. Content entered is persistent and backed up, as well as occasionally or regularly copied down to lower environments.

• Synonyms: prod, public
• Deployment cycle: Defined by the organization
• Availability: Close to 100%
• Who uses it: Customers

Common Misconceptions

Features that have been deployed to production are not necessarily available to everyone. A common mechanism to hide such features are feature-toggles, switches than can enable and disable features at runtime through configuration or content. In advanced setups, you could even let users decide to opt into new features.

Putting it all together

Knowing all the stages now, here is a typical flow of a single feature, up until production: It all starts with the feature being created on the Local machine of a developer. This is an iterative process and includes some broken versions that no one else ever sees. Once the developer is happy with the result, he promotes the feature to Integration, where it is running together with changes from the rest of the team. The developer can get feedback from the feature requester and rework issues that might have been spotted. After the requester is happy with the state, the feature is promoted to Test, where it runs on production-like content. The stakeholders determine whether the feature is fit for production and approve it, after which it is released to Production during the next deployment.

What do you think?

Do you agree? Did you experience situations where printing culture slowed down your publication process? Is this article helpful and would you enjoy similar content? Let me know in the comments.

Aknowledgements

Photo by Hans-Peter Gauster on Unsplash