In software development, staging is the process of testing your code in a live environment before pushing it to production. A staging environment i...
For further actions, you may consider blocking this person and/or reporting abuse
Days of “let’s deploy and be on the lookout” are gone indeed.
developWorks well for us!
I think heroku allows you to do all of this by default. It has staging and production environments. Plus it has review apps that can be linked to an issue in JIRA.
In Deploy Now, we've implemented the following mechanic:
If a dev opens a new branch in addition to main, we directly deploy it under a preview URL using the same build workflow that is also used in "main". The staging environment receives a generated preview URL incl. SSL. One the branch gets deleted/merged, we delete the staging environment. But if someones pushes to main, updates go live instantly.
Does this sound like a good workflow for you, or would you design it differently? @vjnvisakh & @joolsmcfly
Sounds pretty good to me except for small details.
We deploy feature branches we deem deployable/advanced enough (test suites are automatically run only if you push to a branch that has an open pull request).
If you're in the early stages of a new feature then it's not very useful to have a preview URL as it might be broken.
Our main branch is protected so you cannot push to it directly. You have to open a pull request first. That way we make sure tests are run and that someone reviews your changes.
We merge pull requests only if the matching pipeline (our test suite basically) is successful and if at least one person validates your PR.
Hope this helps!
Helps, thanks a lot :)
Indeed but review apps only work with GitHub if I understand the doc correctly: devcenter.heroku.com/articles/gith...
ah! yes. heroku only has github support currently.
Staging rules!
This!
Totally agree!
I totally agree with you on this. Before going live staging is a must dor developers.
Couldn't agree more. Never trust localhost alone
Happy designer, happy live.
My company goes a step during our process of deployment including deploying to the following websites:
Also we have protected (can't be deleted) git branches called:
Sounds interesting. How do you structure and store feedback between the project manager and the responsible developer? @hollyw00d
@roberts we message the responsible project manager to view a link in a STAGING environment. Often I also sent them an IM (Instant Message) message as well to ensure they receive it.
Then if the responsible project manager approves the link in a STAGING environment that we push the work live (AKA deploy to PROD).
Makes sense. So an automatic notification for the project manager whenever a Staging environment was created/updated and a tool integration where the project manager could drop documented feedback and e.g. annotate screenshots would feel overeingineered? @hollyw00d
We don't have an automated system yet to contact a project manager for to review work that is pushed to STAGING. That would be a great idea.
Thanks for Sharing Really Appreciated your efforts. Now Starting following you!
Thanks a lot! :)
Since we have multiple teams working in parallel, it's best for the team to stay updated with the progress of development. Once the development is done for a sprint we demo it to the client on staging itself. We then move it to QA env once they are satisfied and then goes to internal testing by clients and then to production.
Did you implement any automatic notification mechanisms whenever an update on a stage gets rolled out, like Slack/Email notifications? @vjnvisakh