3
10 Comments

Question for professional developers

If you work as a developer like me on a team releasing a WEB APP I want to ask:

  1. Do you release continuously or periodically?
  2. How do you ensure a release doesn't mess up styling (either cosmetic or serious i.e. a form element is hidden that shouldn't be)
  3. Do you run automated tests? On each commit?
  4. Any war stories or big pain points in the last year where someone checked in some bad code and screwed up production, either from a stylistic point of view, or some other way?

Spoiler (if you want to answer the questions do that first please!)

I have an idea touching on these areas to try to prevent screw ups and give more confidence in making sweeping site changes.

The idea is roughly an automated testing solution that will intelligently "Lint" your UI on different browsers to make sure nothing is broken. You'd probably add a line to your travis.yml or appveyor.yml file (or whatever script you run on each build) and then it will pass/fail based on testing your app's UI in a real browser, but with minimal or no test writing from the developers.

  1. 2
    1. When there is a new feature. If it is every 2 days, I do it every 2 days. If it is every 3 months, I do it every 3 months.
    2. Specific CSS
    3. Never
    4. Nop (lucky! for now)
  2. 2
    1. Continuously
    2. Create a staging environment that will match the live environment and if something is messed up there, just fix it and apply the changes until you get the desired outcome.
    3. I run automated tests on the staging environment per commit. I use other branches (ie. feature/whateverfeature) to do work on until I merge to staging for testing.
    4. I haven't hit that wall yet and I hope I never have to. (I know I will someday)
  3. 2
    1. Continuous to DEV and Stage. Periodically to Prod
    2. Code must be peer reviewed before release to Stage env. Once approved on stage by the client, it is then released to the Prod env.
    3. Only automated tests we run is to make sure code compiles and is properly formatted
    4. No bad code has been deployed to production. There are too many safe guards in place to ensure this.
  4. 2
    1. Continuously
    2. End-to-end automatic testing
    3. I run them on develop before pushing to server. I could easily integrate them on CD/CI process (we use Jenkins) and didn't do it because my workflow doesn't really need it.
    4. I will explain our workflow instead:
      We have 2 main branches: master + stage and all development is on local with feature-branches ex: "rgpd-cookie-compliance".
      We do pull requests from this feature-branches to stage to send to customer/QA for validating the feature and when approved we do the pull request into master.
      Both main branches (master + stage) are automatized deployments with Jenkins. Usually just to connect to servers with ssh to run something like "git pull && composer install && yarn && yarn build:production"

    I think that to integrate some end-to-end testing on multiple browsers adn devices could be something cool, actually I know about https://www.browserstack.com/ even if I never used personally (quite pricey for my needs).

    Hope it helps ;)

  5. 2

    1- Continuously.
    2- Mostly manual checks. I've been using Tailwind since its beginning, that helps a lot to not have unexpectedly messed up pages.
    3- I usually work alone so I don't do automated tests (It's not an excuse, it's just that I'm fine with my current workflow). I run scoped tests while building something, then run the whole test suite before merging to develop and master branches.
    4- The current project I'm working on (I've joined the team after the project's 3rd year) has an awful asset (frontend static files like CSS and images) management. Everytime we deploy it messes up the whole site and I, after 4 months, still cannot figure out why.

  6. 2

    I think the answers for these questions are straightforward. Many people would respond yes so they seem a bit like a straw man.

    Did you check out comp working on the same problem?
    https://www.parrotqa.com/

    Not sure if there is a lint tool which does the same.

  7. 2
    1. Continuously!
    2. For serious stuff, end–to–end tests. For cosmetic stuff, we used to do CSS snapshot testing but there were too many false positives.
    3. We run automated tests on each merge request and on commits to the default branch, which get deployed.
    4. I checked in a "planned maintenance" full-screen takeover, but the polling to hide it when the maintenance was over didn't work and people had to restart the app!

    Your idea sounds cool, is it kind of like Percy? https://percy.io

    1. 1

      Thanks Jake for the answers.

      Percy looks nice and very full of features. That is sort of "one end" of the spectrum of where the idea can go. The other is for simpler apps that just need some kind of "checklist validation" of their UI, and maybe it would be more applicable to non-developers or small dev teams.

  8. 1

    Here is my answers by the way :-)

    1. Periodically because there is a bit of manual testing we like to do before release.
    2. Mostly selenium tests taking snapshots and comparing before/after. Some of it is covered in unit tests. And finally there is manual testing.
    3. Yes every commit even on a pull request.
    4. Not in this job. We've had down time but that is because of upstream cloud services giving up the ghost, and these problems have led to hardening of our processes.
  9. 1

    Thanks everyone. Sounds like Continuous integration (or non continuous but not ridiculous lengths of time) is the norm in this sample! I've recently worked at places that didn't so this is a nice surprise. I wonder if there is a correlation between people who are indie hackers only work at places that have modern tooling :-).

    Answers to question 2 show a bit of a pain point and I feel it too at work. I might investigate and thing about that further, so thanks for that insight. To summarise it sounds like for most people 2 is manual (and therefore time consuming?) but someone attempted to automate it but it failed too often, and one person has got it automated.

    3 has varying answers and I guess that naturally depends on the size of the project (in terms of LoC, team size) because I too will not bother if I am doing a side project, but it is essential for work.

    1. sounds like it can happen to about half the people here.

    Like @mdo says I may have asked the wrong questions, or not the ideal ones. But it has given me some insight so thanks for your detailed answers.

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 49 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 28 comments My Top 20 Free Tools That I Use Everyday as an Indie Hacker 14 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments